Date: Fri, 31 Jan 1997 11:48:47 -0800 (PST) From: Chris Newman <Chris.Newman@innosoft.com> 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. I agree with your desire, but perhaps a better way to say it would be something simpler and more general, e.g. ``Avoid time zone rule names if possible''. You can suggest not using time zone rule names when generating a time stamp for a past event. But it should be OK to use them when copying time stamps as part of bulk data transfor.
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. That's perhaps true in theory, but in practice `Expires:' often uses non-UTC times, because it's more convenient for many senders. I just took a totally non-random sample of our news database (I ran `find' until I got tired); fewer than half the Expire: lines used UTC (only 16 out of 39 articles). The cost of requiring news servers to support the "future date" format is far too high, IMHO. News servers already have to parse RFC 822 dates, together with lots of ad-hoc date formats that aren't standardized. Adding support for the future date format would be in the noise, particularly since the source code to do it is public domain and widely available. So far, the only case I know of where the "future date" format is really necessary is for calendaring and scheduling. The same sorts of issues that have arisen with news servers, and which the Usenet community has had to deal with for many years, will arise once calendaring and scheduling become widely popular. Usenet is a good place to look for ideas about how calendaring time stamps will really work in practice. I'm not seriously proposing that Usenet switch to the new format time stamps, any more than RFC 822 should switch; but the Usenet experience is valuable nonetheless.