>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)?
Those are only the ones recognized by the draft (generally considered to
be the son of RFC 822).
>> 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?
Neither - "no time zone data".
Let's put it another way - what does nmh currently do if there's no
timezone info included at all? That's how it should treat those messages.
(Whether or not it takes them as GMT and converts it to local or simply
treats it as local is another discussion - I'm not sure which one is
right).
>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.
Well, my only point is that the textual time zones (other than the ones
listed above) are right now entirely arbitrary - so I don't think there
is a good answer. What was happening before wasn't really right either;
are we really _breaking_ anything by fixing something that's been busted
for a long time?
I remember the WG has struggled with this problem for a while; if it
was up to me, I'd listen to their advice. "But that's just me". :-)
--Ken
