[tz] [PATCH] Revert recent pre-1970 changes.

[Stephen Colebourne]

On 1 September 2013 17:09, Paul Eggert <eggert at 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