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