[tz] Preparing to fork tzdb
eggert at cs.ucla.edu
Tue Sep 21 21:44:34 UTC 2021
On 9/21/21 1:49 PM, Tom Lane wrote:
> while the data may be there,
> it's no longer possible to extract it in a way that matches
> prior results.
It is possible to extract it, if you use the patches I mentioned earlier
Admittedly this is effectively something of a fork and I don't favor
this approach, but it is possible.
> Consumers who value data stability are out in
> the cold.
If you value data stability, then the current tzdb repository is better
than going to a one-Zone-per-country rule, because the latter would
cause more data churn than the former does, due to all the Links that
would turned into Zones that would differ before 1970.
> 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
Yes. This mostly affects only timestamps before 1970.
> * with backzone, there are 95 zone files/links that change content.
That also sounds about right. That's the extra data churn I mentioned above.
In other words, if the goal is data stability, you're better off with
the current development repository, than with a fork that goes to a
> 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.
I am not sure how you're counting, but only 11 files represent updates
other than the May rearrangements. Here's the list:
I got this list by using the abovementioned patches.
> I think there is going to be a fork
Any fork won't save you from the before-1970 changes you're concerned
about, unless you give up on equity goals.
More information about the tz