draft-newman-datetime-01.txt

[Paul Eggert]

   Date: Thu, 30 Jan 1997 12:27:58 -0800 (PST)
   From: Chris Newman <Chris.Newman at 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 at 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.