TZ database content

Martin Smoot msmoot at nssolutions.com
Mon Feb 12 15:52:24 UTC 2001


I would think that the primary use for an abbreviation (like EST) is in
the organic world, not the electronic world.  An organic would think
EST.  An electronic would think -0500 (or +1000).

I would think that the abbreviation in the database should be what the
organic user in that area of the world uses, not what is convenient for
the electronic world.  This is not like the commercial airports around
the world where the 3 letter designation has to be unique so your
luggage does not get lost (or maybe that is why it does get lost!).

Antoine Leca wrote:
> 
> 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

-- 
Martin Smoot
Network Storage Solutions
703-834-2242
msmoot at nssolutions.com         www.nssolutions.com



More information about the tz mailing list