Antoine Leca wrote:
Garrett Wollman wrote:
... I know the tz library and database is in use by several commercial vendors with extensive localization programs (e.g., Sun). Do those vendors make an effort to translate the tz strings as well, so that `EST' and `EDT' in locale fr_CA come out `HNE' and `HAE'? If so, do they do it by providing a completely localized tz database, or a locally-localized one, or by applying some post-processing on the (English) strings in the standard database?
I do not know. But in the Java libraries I looked at (some years ago), there were the concept of time zone abbreviations, without translations.
I looked at the source code in TimeZone.java. It contains a section of comments headed "Internal Implementation Notes". According to these comments, time zone names and abbreviations can be localized. Each time zone has an N-by-6 array of strings associated with it, where N is the number of locales supported. The six columns are an internal ID, full and abbreviated name for standard time, full and abbreviated name for daylight time, and representative city. These names are stored as localized resource data of the class java.text.resources.DateFormatZoneData???, where ??? is the locale specifier, such as _fr_CA. The notes go on to say, "Since we support approximately 90 time zones and approximately 50 locales, there can be over 4500 sets of localized names. In practice, only a fraction of these names are provided." (I think the figure 90 is outdated, because the source code generates 320 SimpleTimeZone objects. 289 of these have names like America/Los_Angeles; the other 31 are "aliases" for some of the 289, with names like PST.) For names that aren't provided, the default display is something like GMT-0800. Am I right to conclude that each Java user is responsible for acquiring or creating his or her own set of localized names? Yours, Gwillim Law