Mark ----- Original Message ----- From: "Paul Eggert" <eggert@CS.UCLA.EDU> To: "Deborah Goldsmith" <goldsmit@apple.com> Cc: "Tz (tz@elsie.nci.nih.gov)" <tz@lecserver.nci.nih.gov> Sent: Sunday, March 06, 2005 23:04 Subject: Re: Time zone: the next generation
Deborah Goldsmith <goldsmit@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 [1].
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 abbreviations.
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 worth encouraging.
Caveat: the CLDR database <http://www.unicode.org/cldr/data/diff/by_type/dates_timeZoneNames.html> 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.