Greg Black <gjb@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@stanford.edu) <http://www.eyrie.org/~eagle/>