draft-newman-datetime-01.txt

[Chris Newman]

On Thu, 30 Jan 1997, Paul Eggert wrote:
> One possible compromise is to suggest that ambiguous local times be
> accompanied by a UTC offset hint.  This removes the need for the A/B
> notation with all its problems; it also accommodates your desire to
> omit the UTC offset hint in most cases.  The hint can be ignored by
> the receiver for times that are not ambiguous.  Senders clueless about
> future UTC offsets can just emit the current UTC offset; that will
> suffice to remove any ambiguity.

I agree with this.  Although I don't think the UTC offset hint should be
omitted in most cases -- rather I think it SHOULD be included but that
valid reasons exist to omit it occasionally.

> On the contrary, RFC 977 is widely used for network news articles, and
> it often transfers historical dates.  I regularly use it to access
> articles many months in the past, and I know of other sites that use
> it to access articles years in the past. 

Most of the dates that RFC 977 uses are present dates when generated, so
they certainly wouldn't need the timezone names.

> RFC 977 dates are a subset
> of RFC 822 dates, but presumably a successor to RFC 977 would be based
> on the new time stamp standard.

I would hope not -- that would create tremondous interoperability
problems.  The definition of RFC 822/1123 dates needs to be tightened and 
discouraged from use in _new_ protocols.  There's no justification to
replace it in current protocols, IMHO.

> Network news provides an example of why one cannot easily separate
> past from future dates.  A news article can contain an `Expires:'
> header line, which would presumably look something like this with the
> draft standard:

There's no reason why Expires shouldn't use UTC.  The cost of requiring
news servers to support the "future date" format is far too high, IMHO.
So far, the only case I know of where the "future date" format is really
necessary is for calendaring and scheduling.

> One cannot insist that a format be used only for future dates,
> because data continually migrate into the past as time passes.

The format in section 5 should be used whenever possible because it's so
much simpler to process.  Perhaps I can't restrict the format in section 6
to future dates only, but I certainly don't want to see it used when not
necessary.

Thanks for the comments!