On 11/8/21 00:27, Clive D.W. Feather wrote:
Suppose that a new "country" (quotes because not all ISO 3166-1 entries are countries and I *REALLY* don't want to start arguing which ones are) is formed. We now have to split a zone into two with identical post-1970 data.
But what do we use for the pre-1970 data? One of them will have to take data for a city in a different country. Precisely what Stephen has been arguing against!
Years ago when that happened and the old guidelines suggested a new Zone, I filled in the blanks with pre-1970 data mostly from Shanks. After some experience of the problems with this approach I changed the guidelines: with the old appraoch, Shanks's unreliability caused me to put more bogus data into tzdb, and this created more work for me, for the scarce people who help maintain the data, and for downstream users who had to deal with the unnecessary proliferation of Zones. It was a mess better avoided if we don't need to do it, which we don't if we're creating a Zone purely for political reasons.
What I am sensing from your proposal, as well as from some of the followup comments, is a need to further clarify exactly what the tzdb project's interfaces are.
I agree with this. I think it should have priority over the rest of this discussion.
For starters we could include something like the above paragraph, as it describes what I've done in the past. Another clarification is over the role of the names. In the reference implementation if you have "Zone A ..." and "Link A B", there's no difference between the two names A and B: they're both hard links to the same TZif file, neither is "the" name for the file, and nothing in the file's contents tells you what its name is. Much of tzdb database maintenance has assumed this, and it'd be helpful to document this assumption. I'm sure there are other things that need to be documented/clarified. (There always are. :-)