[tz] Preparing to fork tzdb

[Emily Crandall Fleischman]

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 at 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