... | ... | @@ -54,19 +54,21 @@ The final schema restores the original schema and retains backup data (`*_bak`). |
|
|
|
|
|
If you previously upgraded to CiviEvent with timezone support (v5.47.0-v5.47.2), then the fields may have inaccuracies. Upgrading to v5.47.3+ _should_ resolve inaccuracies in some common cases -- but not all cases.
|
|
|
|
|
|
These variables are known to influence the final accuracy:
|
|
|
These variables are known to influence the final accuracy on v5.47.3+:
|
|
|
|
|
|
* __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).
|
|
|
* (_N.B._: For restoring unedited records in 5.47.3+, it should not matter whether 5.47.0-5.47.2 displayed accurate times. It only matters that the restoration is _the exact complement_ of the previous upgrade. This requires keeping the timezone the same.)
|
|
|
* __For recently edited `Event` records__: Editing an event in the web UI may have created an error of +/- 1 hour. This depends on the circumstance of the web-user who made the edit -- ie _when_ they edited and _when_ they are subject to "Daylight Savings Time" (DST).
|
|
|
* (_N.B._: 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.
|
|
|
* __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 using an unintended or inaccurate timezone. Consult your developer on how to identify or correct these.
|
|
|
|
|
|
## Advanced cleanup
|
|
|
|
|
|
If the default upgrade does not produce proper dates and times, there are a few alternative approaches.
|
|
|
If your deployment has a significant risk factor -- or if you observe improper dates/times after upgrade -- then you may need to take a more aggressive approach to restoring dates/times. Here are a few approaches:
|
|
|
|
|
|
* [Options for fine-tuning the 5.47.3 upgrader steps](https://gist.github.com/demeritcowboy/514a3c966f996f1d01270930b7cd0384)
|
|
|
* [Restore dates and times from an older MySQL backup](https://gist.github.com/demeritcowboy/8ce328b9ca13eb735b00832266eaa5c8)
|
... | ... | |