Ken Hornstein <[EMAIL PROTECTED]> writes:
> 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
Guess I'll have to look at the draft, but does "known" here mean it can only
be one of EST/CST/MST/PST/GMT/UT (and daylight versions)?
> 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.
That's not real clear. So are they recommending a timezoneless date be
considered UT or 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".
If you were writing a new mail program, or maintaining one that's only a few
years old, especially if said program didn't have mailbox import facilities,
I'd say that'd be reasonable, but there may be people out there that've been
using MH for 20 years straight or something, so I think we should err on the
side of interpreting old mail that doesn't pass muster with the current
standards.
Certainly, as has been stated, we should trust the numeric offset over the
textual time zone where both are present, but I see no good reason to fail
to parse textual time zones when the numeric offset is missing. If that
means sometimes we have to decide on one out of two or more different
interpretations for a given textual zone, so be it.
-----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
[EMAIL PROTECTED] | do not post this private email address
SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
