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.