>> The remaining 3 were not accurately parsed by either 1.0.4
>> or 1.0.4-dev. 1.0.4 identifed 2 MET's as +0700, although the mail
>> headers disagree, and MSK (which stands for Moscow, I believe)
>> as -0700 which it definitely doesn't. 1.0.4-dev treated all three
>> as GMT, which, while not correct, should be controllable by adding
>> more mappings. We just need a fairly authoritive source.
>
>Yeah, presumably there's an RFC?? There's one possible (if not advertised
>as authoritative) source on BSDI's site. I'll forward my September post
>with my date parsing bug findings. It includes the link.
It looks like the latest word on the subject is the most recent draft from
the IETF DRUMS WG, which can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-drums-msg-fmt-09.txt
Short answer: everyone should be using the +/- GMT offset syntax, and the
only officially recognized zones in the standard are EST/CST/MST/PST/GMT/UT
(and the daylight savings time version of all of those).
>From the draft:
Other multi-character (usually between 3 and 5) alphabetic time zones
have been used in Internet messages. Any such time zone whose meaning is
not known SHOULD be considered equivalent to "-0000" unless there is
out-of-band information confirming their meaning.
Earlier, they define "-0000" as:
Though "-0000" also indicates Universal Time, it is used to indicate
that the time was generated on a system that may be in a local time
zone other than Universal Time and therefore indicates that the
date-time contains no information about the local time zone.
Now what y'all want to do with nmh is one thing ... but note that the
zone names have always been problematic (because there was no standard
for them and there ended up being some conflicts), and pretending that
they include no information is "encouraged".
--Ken
