All Day Events span over several days in Outlook and iCal

Based on some research, it seems as though all day events should omit the times for the start and end, and probably don't need the timezone either. Test test this MR.

I've been reading through your updates. And after doing some further research myself, I have a question for you... There is a line of code under the "all day" option (around 167) that says:

// Offset the end by one day for calendar ingestion.
$end->add(new \DateInterval('P1D'));

Why does the calendar need to be offset by a day? When I comment this out I find the the calendar events are entered correctly for iCal and Outlook, and doesn't affect google calendars. Since I"m unsure why the day needs to be offset in the first place, I thought I'd ask.

I removed that line as part of changes proposed here. Are you saying that removing that line alone was sufficient to make all day events work as expected?

Assigning to myself for review with MS Outlook...

I tested the isolated removal of $end->add(new \DateInterval('P1D')); discussed in #5 and #6 and looked at the output in both iCal and Outlook formats.

With this change, the end date resulted in changing from the following day to the same day. Importing this into MS Outlook successfully fixed the issue: the event that previously spanned two days now was listed as occurring only on one day:

Before

• DTSTART:20240705T050000Z: "Fri, 05 Jul 2024 05:00:00 +0000 (GMT)"
• DTEND:20240707T045900Z: "Sun, 07 Jul 2024 04:59:00 +0000 (GMT)"

After removing $end->add(new \DateInterval('P1D'));

• DTSTART:20240705T050000Z: "Fri, 05 Jul 2024 05:00:00 +0000 (GMT)"
• DTEND:20240706T045900Z: "Sat, 06 Jul 2024 04:59:00 +0000 (GMT)"

As can be noted from the data above, this uses the GMT timezone as its baseline time, so the above values (5:00am), when imported into a calendar that expects a 7-hour offset (CST), correctly results in the event that is occurring in the CST timezone to be displayed in the calendar as occurring on Friday, July 05, from 00:00am to 11:59pm (i.e., "All day").

I also tested how this change would affect the Google Calendar link. It *does* result in a change, but apparently not one that has an effect on Google's output:

• Current output: https://calendar.google.com/calendar/u/0/r/eventedit?ctz=America/Chicago... --> Renders as "July 5 to July 5"
• Output with removal of P1D line: https://calendar.google.com/calendar/u/0/r/eventedit?ctz=America/Chicago... --> Renders as "July 5 to July 5"
• Output when the end date is changed to one day in the future (i.e., event spans two days): https://calendar.google.com/calendar/u/0/r/eventedit?ctz=America/Chicago... --> Renders as "July 5 to July 6"

Based on the above, it appears that we simply don't need $end->add(new \DateInterval('P1D')); , and from a standpoint of parsing the code logic itself, it also appears that the 1-day offset added there should not be needed, since the end date as provided by the data stored in the field should already be set to 23 hours and 59 minutes after the start date. I haven't looked into whether this underlying data storage changed since the code was added 3 years ago, but I don't see an scenario, at least when using the smart_date field type, where the code is relevant at this point in time.

I've attached a patch that represents what changes would need to be included in the merge request to make the functional change and to update test expectations.

I've created two merge requests that apply only the change required, that of removing $end->add(new \DateInterval('P1D'));.

• For 1.2.x: 3456833-allday-fix
• For 1.1.x: 3456833-allday-fix-1.1.x

mandclu → closed merge request !17

Merged into 1.1.x and 1.2.x. Thanks for everyone's work on this! Always great when the fix turns out to be simple :)

Automatically closed - issue fixed for 2 weeks with no activity.