Commit 28759b5c authored by Robert Rollins's avatar Robert Rollins

Issue #2127717: Parsed single-day All Day events are now given an end date.

As jakemonO pointed out, the Calendar will not display All Day events which have no
end date value, which means that Date iCal's method of leaving off the end date for
single-day All Day events was a really bad idea. Fortuantely, setting the end date
to the same day as the start date makes the date node display correctly for single-
day events, which was the reason that the end date was being left off in the first
place. This means that every All Day event can simply have it's end date rewound by
one day, and all is well in both the node display and the Calendar.
parent 7f7bafe9
......@@ -232,22 +232,13 @@ class ParserVcalendar {
}
if (module_exists('date_all_day')) {
// If the Date All Day module is installed, single-day All Day events
// will be displayed wrong unless we ignore the DTEND value. Yes, that
// means we may be ignoring work done in other parts of this function,
// but we need that work for when Date All Day isn't installed.
// If the Date All Day module is installed, we need to rewind the
// DTEND by one day, because of the problem with FeedsDateTime
// mentioned below.
$prev_day = iCalUtilityFunctions::_duration2date($property['value'], array('day' => -1));
if ($dtstart['value'] == $prev_day) {
return NULL;
}
else {
// If Date All Day is installed and this All Day event spans
// multiple days, we need to rewind the DTEND by one day, because
// of the problem with FeedsDateTime mentioned below.
$property['value'] = $prev_day;
}
}
}
// FeedsDateTime->setTimezone() ignores timezone changes made to dates
// with no time element, which means we can't compensate for the Date
......@@ -257,7 +248,7 @@ class ParserVcalendar {
$date_string = sprintf('%d-%d-%d 00:00:00', $property['value']['year'], $property['value']['month'], $property['value']['day']);
// Use the server's timezone rather than letting it default to UTC.
// This will help ensure that the date value doesn't get messed up when
// Date converts its timezone as it's read from the database.
// Date converts its timezone as the value is read from the database.
// This is *essential* for All Day events, because Date stores them as
// '2013-10-03 00:00:00' in the database, rather than doing the sensible
// thing and storing them as '2013-10-03'.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment