Chris.Newman at innosoft.com
Fri Jan 31 19:48:47 UTC 1997
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
Thanks for the comments!
More information about the tz