Updated Australian time zone names/strings

[Russ Allbery]

Greg Black <gjb at gbch.net> writes:

> The broken software consists of real mail clients out there that people
> are still using.  Some of that software outputs email with dates in this
> form:

>     Date: Thu, 21 Dec 2000 09:34:42 EST

When used in e-mail, that Date header is not in the slightest bit
ambiguous.  RFC 822 requires as a matter of protocol that that time zone
be interpreted as -0500.  Section 5.1:

     zone        =  "UT"  / "GMT"                ; Universal Time
                                                 ; North American : UT
                 /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
                 /  "CST" / "CDT"                ;  Central:  - 6/ - 5
                 /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
                 /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
                 /  1ALPHA                       ; Military: Z = UT;
                                                 ;  A:-1; (J not used)
                                                 ;  M:-12; N:+1; Y:+12
                 / ( ("+" / "-") 4DIGIT )        ; Local differential
                                                 ;  hours+min. (HHMM)

Section 5.2:

     The other remaining two forms are taken from ANSI standard
     X3.51-1975.  One allows explicit indication of the amount of offset
     from UT; the other uses common 3-character strings for indicating
     time zones in North America.

RFC 822 further requires as a matter of protocol that only those 9
three-character abbreviations, the two-character abbreviation UT, and the
single-character abbreviations A-Z (excluding J) be used as time zone
abbreviations, and that all other time zones use an explicit time
differential.

Any software in Australian time zones that is generating e-mail Date
headers with non-numeric time zones is broken and generating Date headers
with no valid interpretation under a mail standard that is 19 (!) years
old.  I think it's about time that those mail clients get fixed, hmm?

Furthermore, RFC 1123 states:

     There is a strong trend towards the use of numeric timezone
     indicators, and implementations SHOULD use numeric timezones instead
     of timezone names.  However, all implementations MUST accept either
     notation.  If timezone names are used, they MUST be exactly as
     defined in RFC-822.

     The military time zones are specified incorrectly in RFC-822: they
     count the wrong way from UT (the signs are reversed).  As a result,
     military time zones in RFC-822 headers carry no information.

so any software that is generating non-numeric time zones is violating a
SHOULD in a mail standard that is now eleven and a half years old.

> I can't force people who write to me (who are often people I don't know)
> to replace their mail software just because I don't like the dates it
> generates.  However, if the TZ data gave the Australian users
> unambiguous abbreviations for those zones, it would make life easier at
> little or no cost to anyone.

Except that per RFC 822, the "AEST" bit in a Date header like:

    Date: Thu, 21 Dec 2000 09:34:42 AEST

has no actual meaning and can't be relied on to be anything at all.  Given
stuff like IST, if I were writing an e-mail client, I would interpret
anything with a non-822 time zone as being in UTC and warn the user.
Anything else just isn't worth it.

Putting explicit tables into software to deal with e-mail clients written
by people who haven't read *eleven-year-old* standards would just bug me
far too much.

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