2

Just upgraded to CiviCRM 5.47 on WordPress, and some of my plugins are now displaying the incorrect time because they don't know how to interpret the start_date or end_date of an event.

My server has its timezone set to America/Edmonton, as do my events.

After upgrading, I tried creating two events: one this week (Mountain Standard Time, -0700), and one next week (Mountain Daylight Time, -0600). Both events have their time zone set to America/Edmonton.

I created both for 9am-12pm.

Looking at the database, both have their times recorded as 16:00 to 19:00.

1600 UTC is 0900 MST (America/Edmonton) which is correct for the event this week.

For the event next week, 1600 UTC converts to 1000 MDT (America/Edmonton) (and my plugin therefore displays the event time as 10am). This of course is not what I expect: I expect the event to start at 9am, and CiviCRM does display 9am everywhere. It's just my plugin that is failing to understand the start time, because it's not stored as UTC.

I've implemented a workaround at the moment to just ignore the timezone and subtract 7 hours to display the time, but this of course is a hack.

I would expect all times to be stored in UTC.

mysql> select title,id,start_date,end_date,event_tz from civicrm_event \g +-------------+-----+---------------------+---------------------+------------------+ | title | id | start_date | end_date | event_tz | +-------------+-----+---------------------+---------------------+------------------+ | test1 | 295 | 2022-03-10 16:00:00 | 2022-03-10 19:00:00 | America/Edmonton | | test2 | 296 | 2022-03-16 16:00:00 | 2022-03-16 19:00:00 | America/Edmonton | +-------------+-----+---------------------+---------------------+------------------+

My plugin display is wrong:

Plugin output

But CiviCRM display is correct:

Event time under standard time

Event time under daylight time

CiviCRM output

7
  • See also civicrm.stackexchange.com/q/41426/225 although this appears slightly different in that events here after created after the upgrade.
    – Aidan
    Mar 10, 2022 at 9:34
  • There have been changes relating to timezone and I'm not up to speed with them, but test2 in civicrm_event intuitively looks wrong. if 1600 is not UTC then what is it? What plugin is displaying 10am?
    – Aidan
    Mar 10, 2022 at 10:21
  • It sounds like a custom or 3rd party civi extension that isn't aware of the changes yet. Chris can you edit your question and list what plugins you're talking about.
    – Demerit
    Mar 10, 2022 at 13:18
  • See lab.civicrm.org/dev/core/-/issues/2122
    – Aidan
    Mar 10, 2022 at 17:31
  • I can't seem to edit my question (it doesn't seem to recognize it as mine), nor can I respond to comments because my account is too new. :( The plugin is a custom Wordpress plugin I wrote. I'm less concerned about the plugin itself, and more about the fact that CiviCRM is storing times in its events table (civicrm_event) in an arbitrary time offset which is not UTC during dates when daylight saving time is active. Is there a CiviCRM API I should be using to properly convert the time? If I put event.start_time through CRM_Utils_Date::convertDateToLocalTime(), I still get the incorrect 10am. And
    – Chris C
    Mar 10, 2022 at 17:35

2 Answers 2

3

See the analysis by haystack on https://lab.civicrm.org/dev/core/-/issues/2122.

Basically 5.47 is reading and writing event dates using the daylight savings offset at the time of reading/writing, not the offset applicable to the event date. That's badly broken since you would need to know the offset applicable when the event time was saved to work out the intended time!

For anyone using Events who hasn't upgraded yet to 5.47 - don't do it until this is fixed.

If you have, then follow progress on the issue above. You might want to revert to a backup. At the very least, make sure you keep hold of a backup from before you upgraded. Some hosting only keeps backups for a few days.

4
  • "don't [upgrade to 5.47] before it's fixed"... I feel this might crash into "upgrade to 5.47.2 for security's sake!" next week unless people can move fast on this! Mar 11, 2022 at 15:53
  • Yes, very much so.
    – Aidan
    Mar 11, 2022 at 16:04
  • Would this affect UK sites, who would normally be in one timezone?
    – Andy Clark
    Mar 15, 2022 at 18:17
  • Andy - I think it will since the problem is daylight savings, so GMT/BST will be affected.
    – Aidan
    Mar 16, 2022 at 0:13
0

FYI, my website admins have updated the times of events in summer time to use the Europe/London timezone and the correct time.

I have a Wordpress extension that displays forthcoming events. These times were now out by an hour for events in summer time. I've updated the extension smarty template to fix this up for now. I'll double-check as-and-when CiviCRM issues a fix. The list of events is obtained elsewhere using civicrm_api3('Event'...

Without this change, I think the dates were being converted into summer time twice. Previously my code did {$event.event_start_date|crmDate}

The event has 'event_tz', 'event_start_date' and 'event_end_date' string fields. The dates are already in the local timezone ie in summer time. This code converts the dates back to UTC. They are then converted back into local (server) timezone as part of DateTime format(). Writing this up now, I realise that I probably could have done it differently...

{php}
$event = $this->get_template_vars('event');
$tz = $event['event_tz'];
$tz = new DateTimeZone($tz);
$utc = new DateTimeZone('UTC');
$startdate = new DateTime($event['event_start_date'], $tz);
$startdate->setTimezone($utc);
$this->assign('startdate',$startdate->format('jS F Y, g:iA'));
$enddate = new DateTime($event['event_end_date'], $tz);
$enddate->setTimezone($utc);
$this->assign('enddate',$enddate->format('jS F Y, g:iA'));
$this->assign('enddateshort',$enddate->format('g:iA'));
{/php}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.