Re: TR35 (was: Standardize TimeZone ID

From: Philippe Verdy (
Date: Fri May 07 2004 - 19:05:03 CDT

  • Next message: Philippe Verdy: "Re: Phoenician"

    From: "Carl W. Brown" <>
    > > 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