[tz] Preparing to fork tzdb

[Eliot Lear]

[Resending]

I think it's a bad idea to fork for a great many reasons, only a few of 
which are the following:

  * Time confusion going forward, with new inconsistencies being introduced.
  * Implementer confusion in terms of which code base is more
    up-to-date; worse if the code base fragments.
  * Fragmentation of expertise among volunteers

I fear that you drastically underestimate the effort that has been 
required to maintain both the code and the data.

I would suggest an alternative: the policy of this group is set in an 
RFC, and that RFC can be updated if there is consensus in this community 
to do so.  If the community doesn't like the policy, it can change it, 
and continue to gain the benefit of one another.

Eliot

On 20.09.21 10:06, Stephen Colebourne via tz 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20210920/ae69cf5d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://mm.icann.org/pipermail/tz/attachments/20210920/ae69cf5d/OpenPGP_signature.sig>