[tz] Dropping iso3166.tab

David Braverman david at braverman.org
Wed May 22 15:35:05 UTC 2013

A sensible compromise. I would support 1 and 2, and agree with postponing consideration of 3.

David Braverman

-----Original Message-----
From: tz-bounces at iana.org [mailto:tz-bounces at iana.org] On Behalf Of Robert Elz
Sent: Wednesday 22 May 2013 09:14
To: tz at iana.org
Subject: Re: [tz] Dropping iso3166.tab

Personally I'd like to drop countries - not just from zone.tab but
from everywhere, and so avoid all kinds of problems.   But I don't
see that happening any time in my lifetime, unfortunately.

Certainly we should be rid of the political decisions from this project.
We don't need t be making them in fact, as much as possible, we shouldn't
be making any decisions at all, that is not what this project is about.
What we do is collect and publish data.   That's it.   Unfortunately, to
do that we have to make some decisions - including stuff like the name of
the file the data is published in (mostly relatively uncontroversial,
fortunately...) and the names of the data items that are published (more
controversial, though we could reduce controvery by switching to using
completely meaningless labels.)

However, we cannot delegate decisions to the UN, or ISO, or (possibly
aside from people who participoate in this project) to anyone else - none
of them work for us, we do not get to tell them what to do, or to demand
that they make some kind of decision that we need made.

For example (and I know this one is extremely far fetched) suppose that
the people who live in the region of Kosovo, which might or might not be
recognised as a country, sooner or later, were to decide, today, that as
from Sun June 2 2013, they were going to change their timezone, and that
was reported to us, later today.

We would have a week and a half to make and distribute a new tzdata
distribution with the new zone in it.   Tight, but we've done that before.

But, if we're depending upon ISO, or the UN, or someone to decide what
country code to apply, what do we do next?  Frantic phone calls to the
UN secretary general demanding a decision or we'll sack him?   Not going
to work, is it?

Still, we have to publish the data, or we've failed.   We need to make the
decision for any decisions that need to be made.   So, obviously, reducing
the number of those decisions that are needed helps, and where possible,
making those decisions be ones where there is as little scope for argument
as possible.   Then we can go back to just collecting and publishing data,

So, I have a counter proposal to that made by Paul Eggert - with similar
objectives, just achieved in a slightly different way.

Paul suggested 3 operations.   The first, removing iso3166.tab is a no-brainer
we can easily do that - anyone who wants a copy can get it from other sources.

For zone.tab (assuming that the other solution, of simply moving it, and
tzselect, to some other project isn't adopted) rather than making column 1
be a comment, define it to be a region, expressly not a country, and explicitly
not using (however similar they may seem) ISO3166 2 letter identifiers.
Instead define it as simply being a tz project specific identifier used to
group related zones that apply within some tzdata defined region together.

Of course, in practice, most of the time we'll keep using identifiers, that,
by pure accident of course, happen to be the same as the 3166 2 letter 
identifier for the country that has rather similar boundaries to our
region, without ever, of course, implying they are the same, and without
ever claimimng that some city belongs to a particular country - that is none
of our business, nor do we care one way or the other.

Step 3 of Paul's plan I'd avoid for now - that is, merging zones that could
be merged.   Not because it is the wrong thing to do, but because it is a
whole bunch of work for no immediate gain.  All the old zones would still
exist (or seem to exist) in the output from zic (the stuff that people
actually see) because of the "backward" entries we would need to create.
Instead, I'd simply allow zones to be merged if at some future time doing
so will make life easier - so if in the future, something changes that would
need updates to a whole bunch of identical zones, it might at that time be
easier to merge them into one (and add backward links) simply because that's
easier to do than the same edit several times.


More information about the tz mailing list