[tz] Preparing to fork tzdb

Stephen Colebourne scolebourne at joda.org
Mon Sep 20 20:56:09 UTC 2021

On Mon, 20 Sept 2021 at 19:27, Paul Eggert via tz <tz at iana.org> wrote:
> On 9/20/21 11:03 AM, Stephen Colebourne via tz wrote:
> > I also believe that discriminating against countries like Angola and
> > Niger is unacceptable. But the solution to that is the same as it
> > always has been - to include full data for each ISO country, using
> > best efforts for data that is not certain.
> I addressed this issue toward the end of my recent email to Tom Lane
> <https://mm.icann.org/pipermail/tz/2021-September/030422.html>, which I
> sent about the same time you sent your email.

The argument you make is that fixing tzdb to have better historic data
in an equitable way is a big task, which we agree on. But where we
disagree is the need to nuke what we have now as a first step. The
right approach would be to start from the 2021a data and actively add
in the missing pieces to reach the equitable goal.

As I've said before, there are only two equitable solutions for the
default tzdb files (ie minus backzone). Either they contain full
history for every ISO country (even if that history is inaccurate), or
they contain no pre-1970 data at all. It is completely inequitable to
allow only some locations to have pre-1970 data (and to the average
user, the choice *looks* very arbitrary even if it isn't).

> > The *only* good faith move you can make right now is to revert the
> > patch.
> We disagree on this point. This morning I made a different good-faith
> move, by installing the "Revert May patch to zone.tab" patch into the
> development database. I suggested another potential good-faith move in
> that recent email to Tom Lane.

Expecting downstream projects to change their build systems with no
notice to solve an artificially created crisis isn't good project
management. It isn;t appropriate behaviour for the role of TZ

> I continue to think that it would be better to work together to find a
> common solution, than to insist on one unalterable position.

I have absolutely no desire to support a fork. I'm being forced into
it by your unwillingness to listen to this group's feedback and
perform the reversion. All these additional partial reversions have
actually had the effect of making the issue harder to resolve, not

I have also laid out a possible future position for tzdb [1]. But to
move forward, the data set needs to be reset back to 2021a.

The question you as TZ coordinator should consider is which route has
the best outcome?
- revert now, then discuss and agree a long-term solution that solves
the equitability issue
- or, do not revert, and trigger a painful fork, with different
downstream projects choosing one or the other

I have always wanted the first option - forking is not a good outcome.
But the choice is yours to make, not mine.


More information about the tz mailing list