From: "Carl W. Brown" <[EMAIL PROTECTED]> > > 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...
