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!