Answers.Body: <p>See the <a href="https://lab.civicrm.org/dev/core/-/issues/2122#note_70271" rel="nofollow noreferrer">analysis by haystack</a> on <a href="https://lab.civicrm.org/dev/core/-/issues/2122" rel="nofollow noreferrer">https://lab.civicrm.org/dev/core/-/issues/2122</a>.</p>
  <p>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!</p>
  <p>For anyone using Events who hasn't upgraded yet to 5.47 - don't do it until this is fixed.</p>
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-11T15:53:14.133Z
Answers.Text: "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!
Answers.UserDisplayName: artfulrobot
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-11T16:04:29.280Z
Answers.Text: Yes, very much so.
Answers.UserDisplayName: Aidan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-15T18:17:58.667Z
Answers.Text: Would this affect UK sites, who would normally be in one timezone?
Answers.UserDisplayName: Andy Clark
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-16T00:13:10.967Z
Answers.Text: Andy - I think it will since the problem is daylight savings, so GMT/BST will be affected.
Answers.UserDisplayName: Aidan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-11T09:21:43.800Z
Answers.LastActivityDate: 2022-03-11T09:21:43.800Z
Answers.UserDisplayName: Aidan
Answers.Body: <p>FYI, my website admins have updated the times of events in summer time to use the Europe/London timezone and the correct time.</p>
  <p>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'...</p>
  <p>Without this change, I think the dates were being converted into summer time twice.  Previously my code did {$event.event_start_date|crmDate}</p>
  <p>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...</p>
  <pre><code>{php}
  $event = $this-&gt;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-&gt;setTimezone($utc);
  $this-&gt;assign('startdate',$startdate-&gt;format('jS F Y, g:iA'));
  $enddate = new DateTime($event['event_end_date'], $tz);
  $enddate-&gt;setTimezone($utc);
  $this-&gt;assign('enddate',$enddate-&gt;format('jS F Y, g:iA'));
  $this-&gt;assign('enddateshort',$enddate-&gt;format('g:iA'));
  {/php}
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-19T13:08:34.333Z
Answers.LastActivityDate: 2022-03-19T13:08:34.333Z
Answers.UserDisplayName: chriscant
Body: <p>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.</p>
  <p>My server has its timezone set to America/Edmonton, as do my events.</p>
  <p>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.</p>
  <p>I created both for 9am-12pm.</p>
  <p>Looking at the database, both have their times recorded as 16:00 to 19:00.</p>
  <p>1600 UTC is 0900 MST (America/Edmonton) which is correct for the event this week.</p>
  <p>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.</p>
  <p>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.</p>
  <p>I would expect all times to be stored in UTC.</p>
  <code>
  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 |
  +-------------+-----+---------------------+---------------------+------------------+
  </code>
  <p>My plugin display is wrong:</p>
  <p><a href="https://i.sstatic.net/iKzqO.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/iKzqO.png" alt="Plugin output" /></a></p>
  <p>But CiviCRM display is correct:</p>
  <p><a href="https://i.sstatic.net/Cpkyn.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Cpkyn.png" alt="Event time under standard time" /></a></p>
  <p><a href="https://i.sstatic.net/Ifbiq.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Ifbiq.png" alt="Event time under daylight time" /></a></p>
  <p><a href="https://i.sstatic.net/iTmhh.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/iTmhh.png" alt="CiviCRM output" /></a></p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-03-10T09:34:37.720Z
Comments.Text: See also https://civicrm.stackexchange.com/q/41426/225 although this appears slightly different in that events here after created after the upgrade.
Comments.UserDisplayName: Aidan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-03-10T10:21:59.990Z
Comments.Text: 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?
Comments.UserDisplayName: Aidan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-03-10T13:18:26.833Z
Comments.Text: 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.
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-03-10T17:31:01.510Z
Comments.Text: See https://lab.civicrm.org/dev/core/-/issues/2122
Comments.UserDisplayName: Aidan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-03-10T17:35:25.673Z
Comments.Text: 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
Comments.UserDisplayName: Chris C
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-03-10T21:18:02.170Z
Comments.Text: I think we are seeing a similar issue here in CiviCRM for Wordpress both 5.47.0 and 5.47.1. I didn't set up the events on the site but the displayed times look wrong after the Daylight Savings change to move the clocks forward an hour on March 27 in the UK. They display as 5pm to 6:30pm when I'm sure they should be 6pm-7:30pm. I have a separate Wordpress plugin which is displaying the times correctly. I don't know whether to fix that yet! Similar existing events are showing as 6pm - 7:30pm as expected. Thanks in advance for looking into this. Chris [![Configure event screen](https://i.stack.im
Comments.UserDisplayName: chriscant
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-03-23T11:23:06.207Z
Comments.Text: how do you have this 'Event Time Zone' option field in your screenshot? Is this an extension or a global setting?
Comments.UserDisplayName: Guillaume Sorel
Tags: <civievent><timezone>
Title: Event times not stored in UTC in 5.47
ThreadText: # Event times not stored in UTC in 5.47
  
  (Asked by: username_0 on 2022-03-10)
  
  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](https://i.sstatic.net/iKzqO.png)](https://i.sstatic.net/iKzqO.png)
  
  But CiviCRM display is correct:
  
  [![Event time under standard time](https://i.sstatic.net/Cpkyn.png)](https://i.sstatic.net/Cpkyn.png)
  
  [![Event time under daylight time](https://i.sstatic.net/Ifbiq.png)](https://i.sstatic.net/Ifbiq.png)
  
  [![CiviCRM output](https://i.sstatic.net/iTmhh.png)](https://i.sstatic.net/iTmhh.png)
  
  **Tags:** civievent, timezone
  
  > **Comments:**
  > **username_1**: See also https://civicrm.stackexchange.com/q/41426/225 although this appears slightly different in that events here after created after the upgrade.  
  > **username_1**: 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?  
  > **username_2**: 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.  
  > **username_1**: See https://lab.civicrm.org/dev/core/-/issues/2122  
  > **username_0**: 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  
  > **username_3**: I think we are seeing a similar issue here in CiviCRM for Wordpress both 5.47.0 and 5.47.1. I didn't set up the events on the site but the displayed times look wrong after the Daylight Savings change to move the clocks forward an hour on March 27 in the UK. They display as 5pm to 6:30pm when I'm sure they should be 6pm-7:30pm. I have a separate Wordpress plugin which is displaying the times correctly. I don't know whether to fix that yet! Similar existing events are showing as 6pm - 7:30pm as expected. Thanks in advance for looking into this. Chris [![Configure event screen](https://i.stack.im  
  > **username_4**: how do you have this 'Event Time Zone' option field in your screenshot? Is this an extension or a global setting?  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2022-03-11. Score: 3
  
  See the [analysis by haystack](https://lab.civicrm.org/dev/core/-/issues/2122#note_70271) 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.
  
  > **Comments:**
  > **username_5**: "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!  
  > **username_1**: Yes, very much so.  
  > **username_6**: Would this affect UK sites, who would normally be in one timezone?  
  > **username_1**: Andy - I think it will since the problem is daylight savings, so GMT/BST will be affected.  
  
  ---
  
  ### Answer by username_3 on 2022-03-19. Score: 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}
  
  
  ---
  
  