... | ... | @@ -48,10 +48,7 @@ The `Event` entity (`civicrm_event` table) has four fields storing dates and tim |
|
|
| `registration_end_date DATETIME`<br/> | `registration_end_date TIMESTAMP`<br/> | `registration_end_date DATETIME`, <br/> `registration_end_date_ts_bak TIMESTAMP` |
|
|
|
| n/a | `event_tz VARCHAR` | `event_tz_bak VARCHAR` |
|
|
|
|
|
|
The final schema restores the original schema and leaves data (`*_ts_bak`).
|
|
|
|
|
|
* If the automatic upgrade gives accurate times, then you will not need the backup columns.
|
|
|
* If the automatic upgrade gives inaccurate times, then you can use the backups for alternative migrations.
|
|
|
The final schema restores the original schema and retains backup data (`*_ts_bak`).
|
|
|
|
|
|
## Risk Factors
|
|
|
|
... | ... | @@ -59,12 +56,10 @@ If you previously upgraded to CiviEvent with timezone support (v5.47.0-v5.47.2), |
|
|
|
|
|
These variables are known to influence the final accuracy:
|
|
|
|
|
|
* __For un-edited `Event` records__: The server hosting MySQL has a default timezone for MySQL operations. This influences accuracy of _un-edited_ records:
|
|
|
* __For un-edited `Event` records__: The MySQL server has a default timezone (_either stored in its configuration or inherited from the operating system_). This timezone influences accuracy of _un-edited_ records:
|
|
|
* If the default timezone has __remained the same__, these records should convert __correctly+automatically__.
|
|
|
* If the default timezone has __changed__ (e.g. due to server-migration), these records will convert __incorrectly__.
|
|
|
|
|
|
* __For recently edited `Event` records__: Editing an event in the web UI may have created an error of +/- 1 hour. This depends on the intended date and the schedule for "Daylight Savings Time" (DST). In 2022, there are DST transitions on March 13 (US+CA), March 27 (EU), and April 2 (AU+NZ).
|
|
|
* If the DST schedule is __consistent among users__ (_the web-user who runs the upgrade has the same DST schedule as all other web-users_), then `Event`s are likely to convert __correctly+automatically__.
|
|
|
* If the DST schedule is __inconsistent among users__ (_some web-users have March 27 and others April 2_), then `Event`s may still have a __+/- 1 hour error__.
|
|
|
|
|
|
* __Custom code/integrations__: If you have custom code which _creates or edits_ `Event` records (via SQL, BAO, APIv3, APIv4), then it could have stored new dates/times with an unintended or inaccurate timezone. Consult your developer on how to identify or correct these. |
|
|
\ No newline at end of file |