> Whatever you do, don't use those timezone names. Is EST Eastern US time
> or Eastern Standard Time in Australia? The same abbreviation is used in
> both places.
>
> Naming of time zones is a *huge* rathole that you probably just don't want
> to crawl into. The short abbreviations are *not* standardized and are
> quite frequently ambiguous. There are three other prevelant time-zone
> naming schemes: the POSIX one (EST5EDT, for example) is completely
> insufficient to actually represent time zone variations as they occur in
> the real world, the "old Olson" found in most Unix operating systems these
> days with names like US/Pacific doesn't offer enough granularity, and the
> "new Olson" method (the best of the lot) uses names that most people don't
> know (America/Los_Angeles for US Pacific for example).
>
> Basically, you don't want to go anywhere near this mess; it eats people.
Heartily agreed. Having just parsed through several hundreds of
megabytes of mailing list archives and having reported to Graham on
which various date formats Date::Parse chokes on or returns zero from,
I can say with some certainty that one should stay away from timezone
names if at all possible. There are many unambiguous/nonstandard/unknown
timezone names out there.
> I see two reasonable options to go with instead. One is to just use a
> binary flag that says use UTC or not; this is the simplest and most
> reliable to explain. The other is to allow a timezone offset; this
> doesn't deal with daylight savings time and historic time zone changes,
> but it provides enough power for most of what people want to do and if you
> want to deal with the rest you have to deal with time zone naming.
>
> --
> Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
