Hello all, Might I point out that there is another option available — section 4 of RFC 6557 (Procedures for Maintaining the Time Zone Database) [1] provides a mechanism for replacing the TZ coordinator in the case that "The TZ Coordinator is not performing the function in accordance with community wishes." I personally am ambivalent about the changes in question, and overall have very little stake in this, but I would hate to see such drastic action as a fork taken before all other avenues have been exhausted. Best, Emily Crandall Fleischman [1] https://www.rfc-editor.org/rfc/rfc6557.html#section-4 On Mon, 20 Sept 2021 at 04:07, Stephen Colebourne via tz <tz@iana.org> wrote:
Hi all, As most of you probably know, there is a dispute about the tzdb maintainer's recent changes to merge large numbers of time-zones [1][2]. These have the effect of wiping out historic time-zone information on many locations where the data has been in tzdb for many years.
It appears that there is soon to be a new release of tzdb containing these changes. In my opinion, the correct behaviour of the tzdb maintainer would be to revert the controversial changes before doing a release.
In the event that the tzdb maintainer does not revert, consideration must be given to forking the project. The purpose of the fork would initially be to maintain the tzdb data set as it was prior to the dispute. This would then be released in parallel to the original tzdb to ensure that downstream projects do not each do their own thing (ie. to minimize incompatibilities downstream).
Is there support for a fork? Is anyone willing to help out? Is any other group willing to sponsor tzdb (eg. CLDR or Red Hat)?
Please reply to this thread with an indication of support and/or help.
thanks Stephen Colebourne
[1] https://mm.icann.org/pipermail/tz/2021-June/thread.html [2] https://mm.icann.org/pipermail/tz/2021-September/030372.html