<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <p>I think it's a bad idea for a great many reasons, only a few of

      which are the following:</p>

    <ul>

      <li>Time confusion going forward, with new inconsistencies being

        introduced.</li>

      <li>Implementer confusion in terms of which code base is more

        up-to-date; worse if the code base fragments.<br>

      </li>

      <li>Fragmentation of expertise among volunteers</li>

    </ul>

    <p>I fear that you drastically underestimate the effort that has

      been required to maintain both the code and the data.</p>

    <p>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.<br>

    </p>

    <p>Eliot<br>

    </p>

    <div class="moz-cite-prefix">On 20.09.21 10:06, Stephen Colebourne

      via tz wrote:<br>

    </div>

    <blockquote type="cite"

cite="mid:CACzrW9A6EbGkA4LP8w0HbVymuo5u_5eyoBbsB6Z4ov44F_Covw@mail.gmail.com">

      <pre class="moz-quote-pre" wrap="">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] <a class="moz-txt-link-freetext" href="https://mm.icann.org/pipermail/tz/2021-June/thread.html">https://mm.icann.org/pipermail/tz/2021-June/thread.html</a>

[2] <a class="moz-txt-link-freetext" href="https://mm.icann.org/pipermail/tz/2021-September/030372.html">https://mm.icann.org/pipermail/tz/2021-September/030372.html</a>

</pre>

    </blockquote>

  </body>

</html>