Paul Eggert eggert at twinsun.com
Fri Jan 31 20:19:10 UTC 1997

   Date: Fri, 31 Jan 1997 11:48:47 -0800 (PST)
   From: Chris Newman <Chris.Newman at 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.

More information about the tz mailing list