I have a proposal for dealing with the "T" problem: How about at the end of section 5.2, I mention that it may be desirable to substitute a " " for the "T" when displaying times to users (of course the "T" would still be required for Internet protocol interchange). Does this sound like a reasonable compromise?
Date: Thu, 30 Jan 1997 12:27:58 -0800 (PST) From: Chris Newman <Chris.Newman@innosoft.com> it is quite possible that a computer will know the standard timezone name, but not be able to compute future UTC offsets. I don't understand this comment. Currently every computer using America/Los_Angeles time (that is, every computer that knows that it's using Los Angeles local time as opposed to merely being at -08:00 today) either has a table of UTC offsets that extends well into the future, or a simple rule that extends indefinitely. These tables and rules are merely predictions (so they may turn out to be wrong), but any computer that knows a time zone rule name should be able to estimate future UTC offsets. This is a practical consequence of the need to compute past UTC offsets. And even if some computers cannot estimate future UTC offsets, that does not mean that the proposed A/B notation is better than UTC offset hints. A computer that cannot estimate future UTC offsets cannot know when to use A/B, either. Conversely, a computer that had enough information to use A/B would have enough information to estimate future UTC offsets. I continue to maintain that current applications do not have enough information to use the A/B notation correctly in general, even if they are operating on hosts that support the Olson tz interface. UTC offset hints do not have this problem. Since the time is unambiguous (except during offset shift times), I believe it's reasonable and useful to allow the UTC offset hint to be omitted by such computers. 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 can't help pointing out that your argument about local time being unambiguous (except during offset shift times) applies also to past dates, and this leads to the next subject....
why is this format constrained to future dates? Please explain why this constraint is needed.
There isn't any current or proposed Internet Protocol which uses historical dates. 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. 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. 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: Expires: 1999-12-31T23:59:59 America/New_York -05:00 The news article containing this date might be retrieved by a conforming NNTP client in the year 2000. At that point the article expiration date would be in the past, but its `Expires:' line would still be using the ``future'' format. One might argue that a news server should rewrite a header once its time becomes a time in the past, but header-rewriting is greatly frowned upon in NNTP circles, for good reasons which I can elaborate on if asked, and any header-rewriting solution would not be acceptable. As calendaring information becomes more popular and standardized on the Internet, I expect to see more and more examples of this sort of thing. One cannot insist that a format be used only for future dates, because data continually migrate into the past as time passes.
The document sometimes breaks lines improperly (e.g. `1996-12- 20T00:39:57Z').
Anyone know how to fix this using troff? Prepend \% to the word you don't want broken across line boundaries, e.g.: \%1996-12-20T00:39:57 Date: Thu, 30 Jan 1997 09:59:18 -0800 (PST) From: Chris Newman <Chris.Newman@innosoft.com> I have a proposal for dealing with the "T" problem: How about at the end of section 5.2, I mention that it may be desirable to substitute a " " for the "T" when displaying times to users (of course the "T" would still be required for Internet protocol interchange). Does this sound like a reasonable compromise? That sounds reasonable. You might also mention that underscore in time zone rule names may also be displayed as space -- it's a similar situation. People will become used to seeing textual dates without the "T" or underscore, and it may become a common error to replace "T" or underscore with space; so it might be wise to add a clause to section 3 (which deals with how programs should parse nonconforming dates) to say that programs wishing to robustly deal with dates generated by broken software may wish to accept space in place of "T" or underscore.
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!
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.
participants (2)
-
Chris Newman -
Paul Eggert