Ken Hornstein <[EMAIL PROTECTED]> writes:
> >> 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?
It considers the time to be GMT.
> 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).
I fail to see the distinction between the two discussions, but oh well
(we're storing the date as an epoch offset and timezone, so we have to
consider it to be either GMT or local -- there's no such thing as "no
timezone").
> >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
"Entirely" arbitrary? No, clearly there've been accepted conventions,
immaterial of whether they've been officially approved in a standard.
> - 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?
No, we'd just like to work with non-standards-compliant mail tools (e.g. the
Y2K ajustments we make) when it's fairly easy and doesn't affect handling of
compliant mail.
> 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". :-)
They're putting out a general recommendation. That's a different issue than
what to implement in a particular (and very long-historied) mail tool.
-----------------------------------------------------------------------
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.
