From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Fri May 07 2004 - 19:05:03 CDT
From: "Carl W. Brown" <cbrown@xnetinc.com>
> > That is not a problem. The Olson IDs are not guaranteed
> > to be unique, just unambiguous. And there are aliases.
> > Typically these are de-unified for political
> > purposes. Thus you may find that two different IDs produce
> > the same results over
> > the entire period of time in the database.
>
> So which timezone will the tr_TR locale in a TR35 database have?
"Asia/Istanbul" or "Europe/Istanbul" or both?
Both: one is an alias of the other, which exists only as a convenience for
users. However, should the eastern part of Turkey use a different timezone,
tr-TR would not indicate the applicable timezone (this is what happens to the
"en-US" locale, that spans many timezones).
This is a good justification for a separate locale setting for TZ in POSIX
locales, so a US user could set:
LANG=en_US for the default locale, and TZ=America/New_York to adjust the
timezone; some newer syntaxes allow setting the timezone in a combined locale ID
with attributes: "en_US;tz=America/New_York".
However, POSIX locales use legacy syntaxes for timezone IDs like "PST-8PDT",
which specify the GMT offset and abbreviations in the standard and daylight
time. Many of them are referenced in the Olson's database as aliases.
For today's developments, the default timezone in softwares without timezone set
should be UTC (alias Zulu or "Z"), even in a "en_US" locale, but many legacy
applications use the US Pacific Time used in California as a default timezone in
that locale or in the default "C" locale. ;-) I wonder why...
This archive was generated by hypermail 2.1.5 : Fri May 07 2004 - 19:05:35 CDT