On 1 September 2013 17:09, Paul Eggert <eggert@cs.ucla.edu> wrote:
Stephen Colebourne wrote:
The Theory change reinstates the one zone per ISO-3166 region requirement.
I'm afraid that's incorrect. That change would strengthen the requirement beyond what it ever was, by requiring a Zone to be present for every country. That has never been required and has never been the practice in the tz database.
You are mistaken.
Hmm, in reviewing the changes it appears we are both mistaken. The older guideline, which you are proposing to resurrect, does not require "one zone per ISO-3166 region"; it allows a link instead of a zone, and it doesn't require either for uninhabited regions. I relied on your summary of the change rather than looking at the actual wording. So when I wrote "has never been the practice", I was referring to the fact that it's always been the case that some country codes have links and not zones, while the uninhabited ones have neither.
I think we have established certain things here: - that no pre-1970 data will be deleted from any "full" zone - that LMT isn't enough reason for a separate "full" zone Given those, I have no problem with the zone ID for one ISO-3166 pointing at another, although I strongly believe that the "shared data" commentary I added is helpful to reduce pain. But I do require those links to be in the main files, not in "backward". The intention of the Theory file at that point was IMO to refer to the main database. The "backward" file is solely about backwards compatibility, an entirely different problem. The proposed patch reinstates the Theory lines, and move the Link definitions back to the main files (and not much else IIRC).
Since we do not remove names, and we already cover the inhabited ISO 3166 codes, the only reason to resurrect the older guideline would be to commit ourselves to the creation of a new link or zone in response to a new country code, or an existing one that becomes inhabited. Say, for example, the UN headquarters declares independence so the folks at ISO 3166 decide to add a code UN for the United Nations, or suppose the United States splits apart into the Red States and the Blue States. In either case, we shouldn't commit ourselves to creating new zones or links in response to these political developments. If the old names continue to work, there's no timekeeping reason to change them, and we should insulate our maintenance guidelines from politics as much as we can.
The ISO-3166 maintenance body has its own set of rules that determine when to create a new code. Such a creation is going to reflect the result of a war or some other major event. In almost all of those cases, there are going to be two sides to whatever "debate"/war was the trigger. The effect of that is that people on one side will want to separate themselves from the other. The extra zone ID thus causes less offence than the minimalist attempt you are pushing for. For example, if you remove the "backward" file today, users are expected to use Europe/Belgrade for all the ex-Yugoslav countries. If the Belgrade zone ID was a number or random sequence of letters, then that would be fine, but its not. As such, it is completely politically unacceptable for those non-Serbian peoples to be using the zone ID of the other side in a major war. Thus, I understand the desire to say "If the old names continue to work, there's no timekeeping reason to change them", but I'm afraid I find it naive when examined against real world events. And since my argument is basically to put back how this database has always worked, I feel on pretty strong ground. thanks Stephen