IST/IDT

[Gwillim Law]

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