... | ... | @@ -3,30 +3,68 @@ This page is a redirect from https://civicrm.org/redirect/event-timezone-5.47 |
|
|
|
|
|
It is intended as a landing-page for sysadmins who need information on the current status of 5.47 / CiviEvent / Timezone support.
|
|
|
|
|
|
Please keep this document short / readable / authoritative. Most discussion and details should go in the Gitlab issue #2122.
|
|
|
|
|
|
Please do update the document when the situation in `5.47@HEAD` changes.
|
|
|
Please keep this document readable / authoritative (reflecting currently released versions).
|
|
|
Discussion should go in the Gitlab issue #2122.
|
|
|
Lengthy scripts/demonstrations should live in other documents -- eg link to Github gists or Gitlab snippets.
|
|
|
-->
|
|
|
|
|
|
## Overview
|
|
|
|
|
|
CiviCRM v5.47.0 introduced an update for CiviEvent to enable timezone support. However, the migration process has multiple issues which affects the accuracy of high-level dates/times ("Start Date/Time" and "End Date/Time").
|
|
|
CiviCRM v5.47.0 introduced [an update for CiviEvent to enable timezone support (dev/core#2122)](https://lab.civicrm.org/dev/core/-/issues/2122). This update had multiple issues which could affect the accuracy of time fields. It was reverted in v5.47.3 -- restoring the original behavior of v5.46.
|
|
|
|
|
|
Restoring the original behavior prevents new inaccuracies and allows organizations to use 5.47 more safely. However, if a system used an affected version, inaccuracies may still exist after upgrading.
|
|
|
|
|
|
There is on-going work to revert or resolve these issues. This page will be revised when fixes are released.
|
|
|
(_This page is ever-green and may be updated if recommendations or techniques change._)
|
|
|
|
|
|
## Current Recommendations
|
|
|
|
|
|
* CiviEvent users should stay on v5.45 (ESR) or v5.46. Both have security updates circa March 16, 2022.
|
|
|
* CiviEvent users who have previously upgraded to v5.47 should stay on v5.47. Optionally, you may wish to:
|
|
|
* Verify the start-time and end-time of any upcoming events.
|
|
|
* Follow new discussion on dev/core#2122.
|
|
|
* Retain any recent backups from before v5.47.
|
|
|
Do not install versions with timezone support (v5.47.0 - v5.47.2 and v5.48.beta1). Only install newer versions (v5.47.3+ or v5.48.beta2+).
|
|
|
|
|
|
## See also
|
|
|
The recommended upgrade path depends on (a) your current version and (b) your available tools+skills.
|
|
|
|
|
|
* [__Gitlab__: dev/core#2122 - Account for timezone on event registration pages](https://lab.civicrm.org/dev/core/-/issues/2122)
|
|
|
* [__Blog__: CiviCRM 5.47.2, 5.46.3, 5.45.4 ESR Security Release (circa March 16, 2022)](https://civicrm.org/blog/dev-team/civicrm-5472-5463-5454-esr-security-release)
|
|
|
| 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 | Novice | Wait. Check back in a few days to see if other users have raised red-flags. |
|
|
|
|
|
|
<!--
|
|
|
* [Sourceforge (Downloads/Mirror)](https://sourceforge.net/projects/civicrm/files/civicrm-stable/): Sourceforge mirrors all historical releases of CiviCRM. You may download v5.46 from here.
|
|
|
--> |
|
|
\ No newline at end of file |
|
|
* Before upgrading to 5.47.3+, review [risk factors](#risk-factors).
|
|
|
* After upgrading to 5.47.3+, decide how to whether and how to address inaccuracies. Here are a few approaches:
|
|
|
* [Review dates and times in CiviEvent](#manual-review)
|
|
|
* [Load dates and times from a previous MySQL backup](#restore-backup)
|
|
|
* [Recompute dates and times from a backup column](#recompute)
|
|
|
-->
|
|
|
|
|
|
## Relevant Data
|
|
|
|
|
|
The `Event` entity (`civicrm_event` table) has four fields storing dates and times. The schema and logic of these four fields has changed. Any inaccuracies created by the upgrade would occur in these fields.
|
|
|
|
|
|
| CiviEvent: Original Schema<br/>(v5.46 and earlier) | Intermediate Schema<br/>(v5.47.0) | Final Schema<br/>(v5.47.3 and later) |
|
|
|
| -- | -- | -- |
|
|
|
| `start_date DATETIME`<br/> | `start_date TIMESTAMP`<br/> | `start_date DATETIME`, <br/> `start_date_ts_bak TIMESTAMP` |
|
|
|
| `end_date DATETIME`<br/> | `end_date TIMESTAMP`<br/> | `end_date DATETIME`, <br/> `end_date_ts_bak TIMESTAMP` |
|
|
|
| `registration_start_date DATETIME`<br/> | `registration_start_date TIMESTAMP`<br/> | `registration_start_date DATETIME`, <br/> `registration_start_date_ts_bak TIMESTAMP` |
|
|
|
| `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.
|
|
|
|
|
|
## Risk Factors
|
|
|
|
|
|
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:
|
|
|
|
|
|
* __For un-edited `Event` records__: The server hosting MySQL has a default timezone for MySQL operations. This 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 |