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

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