Steven Abner <pheonix@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 abbreviations. 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@stanford.edu) <http://www.eyrie.org/~eagle/>