4

After the 5.47 update, event time is displaying wrong values in CiviCRM.

Stored in the DB / this is correct

enter image description here

The stored timezone is Europe/Zurich / also correct

enter image description here

In lists in the backend and in the frontend, these values are NOT respected:

enter image description here

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?

Improve this question
1

3 Answers 3

Reset to default
3

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.

Improve this answer
6
  • You were right, it matters! Have to fix 1200+ events now.
    – Guitarman
    Mar 9, 2022 at 18:03
  • 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.
    – Demerit
    Mar 9, 2022 at 18:05
  • 3
    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;
    – Guitarman
    Mar 9, 2022 at 18:06
  • 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.
    – Demerit
    Mar 9, 2022 at 18:10
  • Of course, the event id's to select are the ones showing the wrong start-/end-dates!
    – Guitarman
    Mar 9, 2022 at 18:10
0

Unfortunately, as mentioned in #2122 (comment 68933), there was no communication about this "wrong feature behaviour".

enter image description here

Improve this answer
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

Improve this answer
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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