[tz] Preparing to fork tzdb

[Tom Lane]

Paul Eggert via tz <tz at iana.org> writes:
> This disagreement is not about whether the data in question are 
> available; it's only about which file they're in. Nothing is being 
> "wiped out" or refused.

The flaw in that assertion is that while the data may be there,
it's no longer possible to extract it in a way that matches
prior results.  Consumers who value data stability are out in
the cold.

I just re-ran my experiment comparing the zoneinfo tree generated
by 2021a to what I get from current tzdb git.  I get the same set
of zone files, except for a couple of expected recent changes such
as Pacific/Kanton.  However:

* without backzone, there are 65 zone files/links that change
contents compared to 2021a
* with backzone, there are 95 zone files/links that change content.

It looks like 25 of the changes are shared between the two trees
and so probably represent actual recent updates, rather than effects
of the May rearrangements.  But that still leaves me with a need to
change the contents of either 40 or 70 zone files for which there is
absolutely no justification other than administrative fiat.  I'm
damned if I do and damned if I don't, and the only thing that's
certain is that I'll have unhappy users.

The same conundrum is going to face every tzdb repackager who
is unwilling to assume that nobody cares about pre-1970 dates.

I think there is going to be a fork, and I think a lot of people are
going to adopt it rather than choose which subset of their users to
annoy.  Of those who don't follow the fork, some large fraction are
going to start using backzone, reasoning that adding poorly-attested
data for some zones is better than removing somewhat-better-attested
data for other zones.  That's going to leave us with three competing
versions of tzdb, which is absolute disaster.  But if you're going
to assign negligible weight to data stability, that's what's going
to happen, because a lot of us *do* value that.

			regards, tom lane