Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!orion.oac.uci.edu!ucivax!gateway
From: kre@cs.mu.oz.au (Robert Elz)
Newsgroups: comp.protocols.iso.x400
Subject: Re: Time zones again.
Message-ID: <5403@munnari.oz.au>
Date: 9 Sep 90 19:52:20 GMT
References: <9008300931.AA19045@jerry.inria.fr>
Lines: 54
Approved: usenet@ICS.UCI.EDU
x-attn: jns
X-Previously-To: comp-protocols-iso-x400%munnari@munnari.oz.au
ReSent-To: mhsnews@ICS.UCI.EDU


In article <9008300931.AA19045@jerry.inria.fr>,
Christian.Huitema@mirsa.inria.fr (Christian Huitema) writes:

> EST can be either Melbourne or Boston;

yes.

> EDT can be either Brisbane or Miami;

No, in Brisbane it would be EST ... (Eastern Summer Time).   That is,
EST can be -0500 +1000 or +1100 (and possibly more).

> CST can be either Adelaide or Chicago;

yes.

> CDT can be either Darwin or New-Orleans..

No, there's no daylight saving in Darwin .... (in Adelaide it
would be CST I believe - same reason as above).

Sometimes Australians (in some weird deference to the US) use
AEST (etc, but still +1000 or +1100) which only makes sense if
compared with USEST.   Some particularly ignorant systems use AESST
(which is an onymoron .. "standard summer time" ??)

> In the absence of a disambiguation algorithm, I intend to apply a "vote
> by head": Eastern and Central North-America is somewhat more populated
> than Australia,

I'd do that too, forget the "originates from Australia" idea, that's
too much work (and still doesn't disambiguate "Standard" from "Summer"
unless you also want to look at the date value, and then decide whether
summer time would have been used at the appropriate date -- good luck.

What's more, in RFC822, EST is defined to be -0500, putting EST there
and meaning something else is simply wrong.

While attempting to interpret these things in some meaningful way is
admirable, I'm not sure itw worth the bother really, RFC822 allows
just 5 (or so) alphabetic timezone strings (excluding the deprecated
US military one character trash) - by all means translate those ones,
I'd just treat the rest as meaning GMT (you could claim "protocol error"
and bounce the message, but that would be a little harsh).

If you do add all this, please arrange to read the mapping from a config
file, don't compile it in anywhere, expecting anyone to actually figure
out what all the zone names are, and then decide which of the ambiguous
mappings is more important in any particular case (if we actually used
EST in messages, I would prefer it to be +1000 (or +1100) here, but in
the rest of the world making it -0500 would make more sense).

kre