[tz] User time zones

Russ Allbery rra at stanford.edu
Thu Dec 8 02:43:31 UTC 2011

Steven Abner <pheonix at zoomtown.com> writes:

> I am not sure of what function Perl would use or your application would
> use if you wished to translate a server in Japan sending a date string
> of "Maintenance will begin at 12:00 JST" and desired to display it in a
> local time string.

One of the reasons why you're finding this example challenging is that
such a time specification is fundamentally broken.  "12:00 JST" is not a
well-formed and unambiguous specification of a time.  This becomes even
more obvious if the example were "12:00 EST", which could refer to a time
in either the east coast of the United States or in Australia (to tie this
back to another perennial discussion of time zone abbreviations).

Thinking that time zone abbreviations are meaningful ways of representing
time is partly a US-centric (and to a lesser extent
Western-European-centric) view of time.  Many of the time zones in the
world have no official abbreviations.  Many others have ambiguous

This is why ISO 8601 does not permit times to be specified using an
alphanumeric time zone representation.  Instead, it requires that time
zones be specified with the -0500 or -0800 or +0100 offset, which is
unambiguous and does not present these problems.  It's also why Internet
standards such as for the Date header field of mail messages no longer
allow time zone abbreviations as the canonical method to indicate the time
zone of a time.

> Why shouldn't a function that deals with time not be allowed to use a
> time zone as input, when it is well understood what the abbreviation
> stands for?

Because it's not well-understood what the abbreviation stands for.  That's
the whole point.

If you have to accept abbreviations because you're attempting to adjust
for broken input, then you have to guess.  I've written code to do that to
deal with obsolete-format Usenet messages; I'm sure many others here have
as well for other applications.  You build a table of time zone
abbreviations and their corresponding offsets and hope that's what the
abbreviation was intended to mean, and you do something for the cases
where you can't guess (usually fall back on UTC).

But you shouldn't lose track of the fact that you're guessing.  You're
taking a stab in the dark at interpreting ambiguous and malformed input,
and some percentage of the time you're going to be wrong.

Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

More information about the tz mailing list