Problem/motivation

In conjuction with Smart Dates, when a user creates an event and selects the "All Day" checkbox, events added to Outlook and iCal span over 1.5 days. The initial find is in the EST timezone. If the date entered was November 9, 12a - 11:59pm, then the date will be imported beginning at 12a November 9 and ending at 11:59pm November 10.

If someone is located in a different timezone, ex: PST, then the dates span over 2+ days. If the all day event was on June 26, it'll begin on 9pm on June 25 and end at 8:59pm on June 27.

Steps to reproduce

  1. On a drupal content type, confirm that smart date is avaiable as a field
  2. When adding a new event day, select the calendar day and then check "All Day" so the event goes from 12a - 11:59pm
  3. On the display page, click on either iCal or Outlook link to add to calendar
  4. Confirm that the event begins on the day selected and end at 11:59pm one day later

Proposed resolution

The timezone appears to be affecting how all day events are added to Outlook and iCal. There needs to be a way to pass the required parameters without modifying the all day event so that the event begins and ends within the same day.

This module uses Gitlab CI for automated testing of proposed code changes. To contribute code changes, create a merge request. Patch files will not trigger automated testing and are not sufficient for review.
CommentFileSizeAuthor
#8 3456833-complete-8.patch4.02 KBmark_fullmer

Issue fork addtocal_augment-3456833

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

ladytekla created an issue. See original summary.

mandclu made their first commit to this issue’s fork.

mandclu opened merge request !14

mandclu’s picture

mandclu commented
Status: Active » Needs review

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.

ladytekla’s picture

ladytekla commented

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.

mandclu’s picture

mandclu commented

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?

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented
Assigned: Unassigned » mark_fullmer

Assigning to myself for review with MS Outlook...

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented
Assigned: mark_fullmer » Unassigned
Status: Needs review » Needs work
StatusFileSize
new 3456833-complete-8.patch4.02 KB

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:

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.

mark_fullmer opened merge request !17

mark_fullmer opened merge request !18

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented
Status: Needs work » Needs review

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

  • mark_fullmer committed 92a40f84 on 1.1.x 
    Issue #3456833 by mandclu, mark_fullmer, ladytekla: All Day Events span...

  • mark_fullmer committed 92a40f84 on 1.2.x 
    Issue #3456833 by mandclu, mark_fullmer, ladytekla: All Day Events span...

mandclu closed merge request !17

mandclu’s picture

mandclu commented
Status: Needs review » Fixed

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 :)

Status: Fixed » Closed (fixed)

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