Paul Eggert via tz <tz@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