Event-Time-Zone-Implementation-Planning.md

@@ -73,6 +73,8 @@ There were some difficulties it would be nice to avoid in future, related to the
    * Stuff can go missing.
    * There's an incentive with big PRs to "get this merged before it goes stale", which is not an ideal.
 2. (Theoretical, but has happened elsewhere.) Possibly another PR that gets merged requires a change to the code, but it gets rebased verbatim, and doesn't get retested and then fails later.
+   * CiviCRM developers and end users following the TZ Issue and PR were either unable too or had significant barriers to test and review the PR. It was only when CiviCRM 5.47 was released when they could download and try it out for themselves. This significantly reduced the number of people able to be involved in reviewing and providing feedback.
+   * Changing the date/time for a system to test in pre-DST and post-DST environment is difficult for many and in cases where CiviCRM is on a hosted service, impossible.
 3. (Theoretical/Opinion) It is offputting and difficult to do code review for such PRs. Perhaps fewer people than normal looked at the code.
 
 It was mentioned at one point in the review to break it up, but it seemed difficult to do at the time. Perhaps if being refactored it can be planned in a way this can be achieved.
@@ -127,3 +129,7 @@ CiviCRM is an application/framework/platform that integrates with several other
 * __CiviCRM__:
     * _Settings_: Does not provide its own timezone setting. Inherits the active timezone from Drupal/WordPress. Propagates the setting to MySQL+PHP. (But has a bug here - it propagates the _current offset_ rather than the _timezone_. This misbehaves when crossing a DST boundary.)
     * _Formats_: Uses MySQL-style strings (`YYYY-MM-DD hh:mm:ss`) and a mix of MySQL `DATETIME`/`TIMESTAMP`. (`DATETIME` for storing nominal perspective; `TIMESTAMP` for canonical+personal perspectives.)
+
+## Related Tasks
+
+https://lab.civicrm.org/dev/core/-/issues/3152