Answers.Body: <p>Yes I mentioned this on the PR that added timezone support and on the associated lab ticket and also in product maintenance in the chat channel but you're the first person who seems to agree that it matters.</p>
  <p>Any existing events that are not in the same daylight savings period as the date you do the upgrade will have a time that is off by an hour (e.g. if you do the upgrade today, then existing events in April/May etc. If you do the upgrade in April, then existing events in November/December, etc.)</p>
  <p>There's currently no known automatic fix for it. You need to update those events manually.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-09T18:03:57.683Z
Answers.Text: You were right, it matters! Have to fix 1200+ events now.
Answers.UserDisplayName: Guitarman
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-09T18:05:54.640Z
Answers.Text: My best guess on why the lack of interest may be because on many sites the time has been wrong forever already (because of lack of timezone support), so they already have ways of dealing with it, like hiding the time field and putting it in the description.
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-09T18:06:32.647Z
Answers.Text: It's possible to update/fix via mySQL in the following way:
  UPDATE `civicrm_event` SET `start_date` = ADDTIME(`start_date`, '01:00:00') WHERE `civicrm_event`.`id` BETWEEN X AND Y; 
    UPDATE `civicrm_event` SET `end_date` = ADDTIME(`end_date`, '01:00:00') WHERE `civicrm_event`.`id` BETWEEN X AND Y;
Answers.UserDisplayName: Guitarman
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-09T18:10:12.310Z
Answers.Text: Cool. Using `id` can work but you might want to use the daylight saving boundary dates instead, since you don't want to update events with a time that are correct as of the upgrade.
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-09T18:10:57.690Z
Answers.Text: Of course, the event id's to select are the ones showing the wrong start-/end-dates!
Answers.UserDisplayName: Guitarman
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-09T18:14:04.690Z
Answers.Text: Doing an export of the civicrm_events table and to previously filter the respective dates is much recommended.
Answers.UserDisplayName: Guitarman
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-09T17:59:34.800Z
Answers.LastActivityDate: 2022-03-09T17:59:34.800Z
Answers.UserDisplayName: Demerit
Answers.Body: <p>Unfortunately, as mentioned in <a href="https://lab.civicrm.org/dev/core/-/issues/2122#note_68933" rel="nofollow noreferrer">#2122 (comment 68933)</a>, there was no communication about this &quot;wrong feature behaviour&quot;.</p>
  <p><a href="https://i.sstatic.net/teE40.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/teE40.jpg" alt="enter image description here" /></a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-09T18:02:14.970Z
Answers.LastActivityDate: 2022-03-09T18:02:14.970Z
Answers.UserDisplayName: Guitarman
Answers.Body: <p>After the change to daylight saving time, every single event is displaying the wrong start-/end-time, unfortunately.</p>
  <p>Also the corrected events after the 5.47 upgrade.</p>
  <p>Changing DB-columns start_date and end_date back to DATETIME solved the issue as a &quot;quickfix&quot;, as expected and mentioned <a href="https://lab.civicrm.org/dev/core/-/issues/2122#note_70251" rel="nofollow noreferrer">HERE</a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-28T01:38:27.423Z
Answers.Text: 5.47.3 has now been released
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-27T16:48:35.510Z
Answers.LastActivityDate: 2022-03-27T16:48:35.510Z
Answers.UserDisplayName: Guitarman
Body: <p>After the 5.47 update, event time is displaying wrong values in CiviCRM.</p>
  <p>Stored in the DB / <strong>this is correct</strong></p>
  <p><a href="https://i.sstatic.net/XC7m0.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/XC7m0.jpg" alt="enter image description here" /></a></p>
  <p>The stored timezone is Europe/Zurich / <strong>also correct</strong></p>
  <p><a href="https://i.sstatic.net/STKf4.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/STKf4.jpg" alt="enter image description here" /></a></p>
  <p>In lists in the backend and in the frontend, these <strong>values are NOT respected</strong>:</p>
  <p><a href="https://i.sstatic.net/pwTF1.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/pwTF1.jpg" alt="enter image description here" /></a></p>
  <p>CMS timezone-setting and Civi setting are equal/didn't change.</p>
  <p>Probably, the daylight saving time has not been respected while implementing the new timezone-feature... as this issue only shows up for events after march 27th.</p>
  <p><strong>What else could be wrong?</strong></p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-03-10T10:23:03.247Z
Comments.Text: See also https://civicrm.stackexchange.com/q/41434/225 (different but related)
Comments.UserDisplayName: Aidan
Tags: <civievent><timezone>
Title: Wrong time after 5.47 update
ThreadText: # Wrong time after 5.47 update
  
  (Asked by: username_0 on 2022-03-09)
  
  After the 5.47 update, event time is displaying wrong values in CiviCRM.
  
  Stored in the DB / **this is correct**
  
  [![enter image description here](https://i.sstatic.net/XC7m0.jpg)](https://i.sstatic.net/XC7m0.jpg)
  
  The stored timezone is Europe/Zurich / **also correct**
  
  [![enter image description here](https://i.sstatic.net/STKf4.jpg)](https://i.sstatic.net/STKf4.jpg)
  
  In lists in the backend and in the frontend, these **values are NOT respected**:
  
  [![enter image description here](https://i.sstatic.net/pwTF1.jpg)](https://i.sstatic.net/pwTF1.jpg)
  
  CMS timezone-setting and Civi setting are equal/didn't change.
  
  Probably, the daylight saving time has not been respected while implementing the new timezone-feature... as this issue only shows up for events after march 27th.
  
  **What else could be wrong?**
  
  **Tags:** civievent, timezone
  
  > **Comments:**
  > **username_1**: See also https://civicrm.stackexchange.com/q/41434/225 (different but related)  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_2 on 2022-03-09. Score: 3 | Accepted answer
  
  Yes I mentioned this on the PR that added timezone support and on the associated lab ticket and also in product maintenance in the chat channel but you're the first person who seems to agree that it matters.
  
  Any existing events that are not in the same daylight savings period as the date you do the upgrade will have a time that is off by an hour (e.g. if you do the upgrade today, then existing events in April/May etc. If you do the upgrade in April, then existing events in November/December, etc.)
  
  There's currently no known automatic fix for it. You need to update those events manually.
  
  > **Comments:**
  > **username_0**: You were right, it matters! Have to fix 1200+ events now.  
  > **username_2**: My best guess on why the lack of interest may be because on many sites the time has been wrong forever already (because of lack of timezone support), so they already have ways of dealing with it, like hiding the time field and putting it in the description.  
  > **username_0**: It's possible to update/fix via mySQL in the following way: UPDATE `civicrm_event` SET `start_date` = ADDTIME(`start_date`, '01:00:00') WHERE `civicrm_event`.`id` BETWEEN X AND Y;    UPDATE `civicrm_event` SET `end_date` = ADDTIME(`end_date`, '01:00:00') WHERE `civicrm_event`.`id` BETWEEN X AND Y;  
  > **username_2**: Cool. Using `id` can work but you might want to use the daylight saving boundary dates instead, since you don't want to update events with a time that are correct as of the upgrade.  
  > **username_0**: Of course, the event id's to select are the ones showing the wrong start-/end-dates!  
  > **username_0**: Doing an export of the civicrm_events table and to previously filter the respective dates is much recommended.  
  
  ---
  
  ### Answer by username_0 on 2022-03-09. Score: 0
  
  Unfortunately, as mentioned in [#2122 (comment 68933)](https://lab.civicrm.org/dev/core/-/issues/2122#note_68933), there was no communication about this "wrong feature behaviour".
  
  [![enter image description here](https://i.sstatic.net/teE40.jpg)](https://i.sstatic.net/teE40.jpg)
  
  
  ---
  
  ### Answer by username_0 on 2022-03-27. Score: 0
  
  After the change to daylight saving time, every single event is displaying the wrong start-/end-time, unfortunately.
  
  Also the corrected events after the 5.47 upgrade.
  
  Changing DB-columns start\_date and end\_date back to DATETIME solved the issue as a "quickfix", as expected and mentioned [HERE](https://lab.civicrm.org/dev/core/-/issues/2122#note_70251)
  
  > **Comments:**
  > **username_3**: 5.47.3 has now been released  
  
  ---
  
  