@@ -35,6 +35,8 @@ The start and end dates have traditionally provided the _nominal perspective_ (*
* It provides backward-compatibility for [relevant screens/tools/APIs](#affected) -- by returning the start and end dates in the same way. (_If you call `Event.get +w id=4 +s start_date` in v5.30 and v5.60, you should get the same value._)
* Screens may be updated incrementally to give richer information (using any of the columns, depending on the downstream goals+preferences).
Note that "universal time" is based on current projections but DST rules may vary in the future, so since the nominal date/time/timezone is authoritative, the universal time may need to be re-calculated. (See [examples](https://www.vertabelo.com/blog/the-proper-way-to-handle-multiple-time-zones-in-mysql/#does%20this%20data%20represent%20a%20point%20in%20time%20in%20the%20past%20or%20in%20the%20future?).)
Changes required to support timezones:
1. Addition of DATETIME columns to hold the GMT date & time for indexed sorting:
...
...
@@ -54,7 +56,7 @@ Changes required to support timezones:
6. An additional token to show the event timezone †
7. Changes to various system workflow message to display timezone information with event messages †
8. Additional fields to the API to show the event timezone †
9. Process to re-calculate universal times after timezone rule changes.
† Already implemented in original PR
...
...
@@ -158,6 +160,12 @@ Sorted by `Status,Environment`:
- First attempt at introducing timezones for events (V1 above): https://lab.civicrm.org/dev/core/-/issues/2122
- Useful reading (linked in above PR): ["Today I learned about MySQL and timezones"](https://javorszky.co.uk/2016/06/06/today-i-learned-about-mysql-and-timezones/), ["The Proper Way to Handle Multiple Time Zones in MySQL"](https://www.vertabelo.com/blog/the-proper-way-to-handle-multiple-time-zones-in-mysql/)
