Time zone: the next generation
mark.davis at jtcsv.com
Mon Mar 7 17:34:17 UTC 2005
----- Original Message -----
From: "Paul Eggert" <eggert at CS.UCLA.EDU>
To: "Deborah Goldsmith" <goldsmit at apple.com>
Cc: "Tz (tz at elsie.nci.nih.gov)" <tz at lecserver.nci.nih.gov>
Sent: Sunday, March 06, 2005 23:04
Subject: Re: Time zone: the next generation
> Deborah Goldsmith <goldsmit at apple.com> writes:
> > On Mar 6, 2005, at 1:45 AM, Paul Eggert wrote:
> >> (6) Do we add support to represent time zone abbreviations in other
> >> locales, e.g., HNE for Eastern Standard Time for French writers?
> > That data is already in CLDR .
> Some of the data is there, but as far as I can tell there's no
> programmatic way to generate the proper information from the union of
> CLDR and the tz database.
> To take an extreme example, the abbreviation "LMT" can mean either
> "Local Mean Time" or "Lisbon Mean Time", and as far as I can see the
> CLDR infrastructure provides no way to tell which is which for
> Europe/Lisbon time stamps. The tz data currently show that Portuguese
> time stamps before 1884 used local mean time, and that from 1884-1911
> they used Lisbon Mean Time, but the only think you'll find in the tz
> database proper, outside of comments, is "LMT" for both. This sort of
> thing is why I think it advisable to add better support for time zone
While CLDR does provide for the option of having timezone abbreviations,
what we have found is that they seldom used, except in the multi-zone
countries, like the US, Canada, Australia, etc, and in that case, typically
just in the languages that are used in that country. Even there there is a
problem, because often the abbreviations used in one country will collide
with those used in another. So while it is available, it doesn't appear
> Caveat: the CLDR database
> currently doesn't have any entries either for Lisbon or for local mean
> time, so to some extent I'm guessing about how the CLDR would actually
> operate once it became complete enough to handle the Portuguese situation.
> > doing so would require adding a lot of infrastructure to handle
> > localization.
> Yes. It would be nice if we could simply point people at CLDR, and
> address the problem mentioned above. Ideally we could point them to a
> complete reference implementation (such as already exists for tz), one
> that would handle the combined tz+CLDR problem.
We have been collecting timezone information in this release, but the way it
works is that if a country only has a single timezone, the default is to use
the name of the country itself, which we already have in a large number of
languages. So you would not see a specific timezone localization for Lisbon
unless that was felt to be important in some particular language.
More information about the tz