... | ... | @@ -25,7 +25,7 @@ The recommended upgrade path depends on (a) your current version and (b) your av |
|
|
| Current Version | Toolset/Skillset | Recommendation |
|
|
|
| -- | -- | -- |
|
|
|
| 5.46 or older | (*Any*) | You may upgrade to v5.47.3+. Dates and times will not be changed. |
|
|
|
| 5.47.0 - 5.47.2; 5.48.beta1 | Professional<br/>(MySQL, PHP, CLI) | Review [risk factors](#risk-factors). Upgrade to v5.47.3+. Report back on [dev/core#2122](https://lab.civicrm.org/dev/core/-/issues/2122). |
|
|
|
| 5.47.0 - 5.47.2; 5.48.beta1 | Professional<br/>(MySQL, PHP, CLI) | Review [risk factors](#risk-factors). Upgrade to v5.47.3+ and check some dates. As appropriate, consider [advanced cleanup options](#advanced-cleanup). Report back on [dev/core#2122](https://lab.civicrm.org/dev/core/-/issues/2122). |
|
|
|
| 5.47.0 - 5.47.2; 5.48.beta1 | Novice | Wait. Check back in a few days to see if other users have raised red-flags. |
|
|
|
|
|
|
<!--
|
... | ... | @@ -48,7 +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 retains backup data (`*_ts_bak`).
|
|
|
The final schema restores the original schema and retains backup data (`*_bak`).
|
|
|
|
|
|
## Risk Factors
|
|
|
|
... | ... | @@ -62,4 +62,10 @@ These variables are known to influence the final accuracy: |
|
|
* __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 |
|
|
* __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.
|
|
|
|
|
|
## Advanced cleanup
|
|
|
|
|
|
If the default upgrade does not produce proper dates and times, there are a few alternative approaches.
|
|
|
|
|
|
* [Restore dates and times from an older MySQL backup](https://gist.github.com/demeritcowboy/8ce328b9ca13eb735b00832266eaa5c8) |