Problem/Motivation

On a site not using UTC as default timezone:

When editing existing Event Series, changing non-date data causes the "Confirm Date Changes" prompt to appear with incorrect dates and times.

When changing date data, the "Confirm Date Changes" shows incorrect dates and times.

The incorrect dates and times shown seem to be the UTC times instead of the website timezone times.

Steps to reproduce

Spin up Recurring Events 2.0.x-dev on simplytest.me

Set default timezone of site to something other than UTC at /admin/config/regional/settings -- my example is Vancouver

Create an Event Series as you wish. My example - Single Event, Dec 12, 2022, 1am 13:00 start, 14:00 end

Save the event series.

Go to /admin/content/events/instances and check the ID of the event instance that was created

Edit the event series. Change only the event title and save.

Get a "Confirm Date Changes" notice even though dates were not changed. Notice that both the "Stored" dates and times and "Overridden" dates and times are incorrect.

Stored has changed to 2022-12-12 09:00pm - 2022-12-12 10:00pm
Overridden has become 2022-12-13 05:00am - 2022-12-13 06:00am

Click on "Confirm Date Changes" and the Event Series is saved.

Note that the correct date and time still shows for the series on its page -- December 12th, 2022 01:00PM - December 12th, 2022 02:00PM

Edit the Event Series again. The correct dates and times appear in the date fields.

Go to /admin/content/events/instances and check the ID of the event instance and it is the same, so a new instance has not been created.

Proposed resolution

Ensure the proper timezone alterations are being performed on the dates so:

a) if not changed, they don't trigger the "Confirm Date Changes" prompt

b) if changed, the "Confirm Date Changes" prompt shows the correct dates and times

CommentFileSizeAuthor
#2 3282568-timezone-date-changes-2.patch7.88 KBchrisla

Comments

endless_wander created an issue. See original summary.

chrisla’s picture

StatusFileSize
new7.88 KB

This fixes it for me. It looks like when building the $diff_array for comparing the original entity datetime and the values from the form, the timezone changes were causing a potentially wrong date.

For the recurring events, the time was being added to the UTC version of the date, which could be a different date from the website timezone date.

Example from DailyRecurringDate.php. The $start_timestamp was being created from the correct time -- because the time is its own separate value. But the $user_input['daily_recurring_date'][0]['value'] is in UTC time and could produce the wrong date -- e.g. Vancouver has an 8-hour time difference so the UTC date could be a day ahead. That means the $start_timestamp could be wrong.

    $user_timezone = new \DateTimeZone(date_default_timezone_get());
    $user_input = $form_state->getValues();

    $time = $user_input['daily_recurring_date'][0]['time'];
    if (is_array($time)) {
      $temp = DrupalDateTime::createFromFormat('H:i:s', $time['time']);
      $time = $temp->format('h:i A');
    }
    $time_parts = static::convertTimeTo24hourFormat($time);
    $timestamp = implode(':', $time_parts);

    $start_timestamp = $user_input['daily_recurring_date'][0]['value']->format('Y-m-d') . 'T' . $timestamp;

I've done the following changes to make sure the date is in the right timezone before the time is attached to it:

    $user_timezone = new \DateTimeZone(date_default_timezone_get());
    $user_input = $form_state->getValues();

    $time = $user_input['daily_recurring_date'][0]['time'];
    if (is_array($time)) {
      $temp = DrupalDateTime::createFromFormat('H:i:s', $time['time']);
      $time = $temp->format('h:i A');
    }
    $time_parts = static::convertTimeTo24hourFormat($time);
    $timestamp = implode(':', $time_parts);

    $user_input['daily_recurring_date'][0]['value']->setTimezone($user_timezone);
    $start_timestamp = $user_input['daily_recurring_date'][0]['value']->format('Y-m-d') . 'T' . $timestamp;

See the patch for all changes. Custom events was a bit different as there ended up being too many timezone changes in the code that was also causing discrepancies.

I have tested on different timezone settings for the website's default timezone.

owenbush’s picture

Interestingly, under some circumstances this seemed to work as is, but I think it was a happy accident. I had my site timezone set as UTC, and had the ability for users to specify their own timezone. I changed my site timezone to Denver, but couldn't recreate the problem. That seemed to be because they had defaulted to use UTC by virtue of being able to use their own timezone. So disabling the ability for users to have their own timezone, and switching to Denver, I saw this problem.

So now I can recreate it, I will test your patch out! Thank you for the work to get this into a patch.

owenbush’s picture

Something is melting my brain today. I'm not sure if this is a pre-existing issue, or even an issue.

I have a site with the timezone set to Detroit (UTC-4)

I had a user who was timezone set to Denver (UTC-6)

The user created an event at 8 am (Denver), and when I view the series listing as an anonymous user I would expect to see them in the site's timezone (Detroit) and I do, I see the event as 10 am (Detroit).

Then I modified the user to no longer use the Denver timezone, and instead to use Detroit, and when I go back to edit the event series, it still shows 8 am in the form (I feel like that should show 10am), saving the event does not trigger the Confirm Date Changes, and it still shows as 10am for anonymous users.

So.. given that I am actually in Denver - I am wondering whether the user's timezone setting in their user entity is not taking effect and it is actually using my browser timezone or something.

Weird. And I don't know if this is working correctly in order to merge this yet. I think I need to think on this and whether there's something else going on.

chrisla’s picture

@owenbush have you tried on simplytest.me with exactly my settings? I can replicate it every time with those settings

timezones are THE biggest pain in the Drupal butt

owenbush’s picture

Sorry I didn't make it clear, your patch definitely fixes the issue you were having. I managed to recreate it and the patch addressed the problem.

And then I came across the other "is it an issue/isn't it an issue" issue

owenbush’s picture

Status: Active » Fixed

Thank you for this patch. I've done a bunch of testing with UTC and non-UTC timezones for both the site, and the editor and things seem to be working as I would expect.

Status: Fixed » Closed (fixed)

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