TZ database content

[Antoine Leca]

John A. Halloran wrote:
> 
> There are good reasons for developing standardized time zone abbreviations.

There are also good reasons to not do that.

> The abbreviation acts as a key to retrieve a full time zone name that is
> meaningful to the local user.

I agree the ultimate goal is to have a full expression.
Where I am unsure is whether abbreviations is the correct way to go.
For example, in France (where we are less common with timezones, and also
where abbreviations are less common than they are in English), the
abbreviations for the timezones (resp. "T.U. + 1" and "T.U. + 2") are much
less understood than the full expression is.

> The abbreviation tells whether the hour in question is standard time or
> daylight/summer time.

No. Your own idea of abbreviation do that. But you can conceive abbreviations
which do not. Look after Australian example.

Or you are really asking for a standardization of the U.S. American system?
But did you consider HAE, HNA, etc.?  ;-)

> With just a numeric hour, you lose that information.

1) there is a solution for that (appending a tag A or B, used in Germany
 some years ago);
2) the information is redondant with the date;
3) I do not really see the use of it. When I am in Western Spain, in Winter
(Standard Time, you'll say), the sun is more ahead of the clock than it is
when I am in Eastern Germany in Summer (Daylight Time, you'll say). So the
place is at least as much important as the abbreviation, here.


> If you do go the numeric route, then it should consist of two parts: the
> standard time zone hour:minutes and the current offset from the standard
> time zone, whether 0 or -1 or whatever the politicians have in effect.

That I completely fail to understand. What is the importance of the "standard
time zone"? Why should the Winter be the reference? Particularly since
"Daylights Time" lasts more than "Standard Time"? And since the timezones
have drifted quite a lot toward West, because our life is less tied to the
sun, and we prefer living in the evening than in the morning (at least, this
is the point in Europe).
Or there is a bias because in English you're using this very word, "Standard".
I do not.

> I see no problem with having more than one abbreviation for a particular
> zone hour, if that allows retrieval of Israel Standard Time versus Eastern
> European Time, for example.

But I do. If you allow that, you are going for the same mess as it is for MIME
types or DNS names: everyone will register its own use, and then there will
be conflicts (IST, EST) with no real (read, "good") solutions.
Also, every softwares will have to record the whole list of registrations,
which quickly proves uneasy. Then, you set up servers (like DNS) to sort the
mess.
(And by the way, these servers will resolve an abbreviation to... the 8601 offset).

Also, please keep this phrase in mind as "reference A".

 
> But, there is competition for certain common abbreviations, such as both
> Israel and India competing for IST.  This is where an organization such as
> the ISO, with which I have no connections, would need to make the hard
> choices.  There is a parallel with the procedure for arriving at ISO
> country codes and language codes.

There is *no* duplicates in either 3166 and 639. Guess why.
Also, the ISO do have a committee in charge of these kind of things. And this
committee just released the relevant standard. It is named ISO 8601, and it
prescibes... numbers.

> To show you what I mean, here is a
> proposal for ISO language codes that appeared on the Linguist List on Feb.
> 4, 2000.
<snip>
> You can see that there is competition for certain abbreviations, and that
> the choice of who gets what can be arbitrary.

Sure. In the past, 'esp' were used for Esperanto (in the LoC, IIRC). 
This has been changed *before* ISO 639-2 came out, to left space to the
obvious, I mean Spanish.
This particular example is between some 400-pound apes (to use Gwillim's
comparisons), so it was sorted out in the development. But there are still
some problems. Since timezones is a moving targets, I expect similar problems
to occur, and the "AEDT" is not a very sympathic solution, I believe.


> The Unix time zone volunteers have as much right as any to decide on the
> conventions for computer/Internet time zone reference.  Since the list
> subscribers are representative of the current world spread of computer
> usage, it would be fair to have nominations for unique abbreviations
                                                  ^^^^^^
You remember "reference A"? Now I do see a problem!

> (from 2 to 5 letters) and tally the votes for and against.

If you insist on unique abbreviations, I do have a solution for the
EST contention: stay with their Australian meaning, and then use the
French Canadian usage for the America: HNE would then mean +0500, and
HAE +0400.

And this is a parallel with ISO: I should highlight that it is very
instructive of the way ISO would solve the problem: Canada might vote
for this proposal, Australia too, and Europe (which basically does not
care about the whole story) might help Canada and Australia, leaving
the USA alone against such a proposal.
And of course, such a standard will gain exactly zero acceptance in the
USA, but who cares? What about ISO 31, anyway?

;-)


Antoine