Message-ID: <EF5D1B2FF253D11195AA00805FE673BFEF8F09@tdmail.teledesic.com>
From: Dan Kohn <dan@teledesic.com>
To: "'John C Klensin'" <klensin@MCI.NET>,
        Nathaniel Borenstein
	 <nsb@si.umich.edu>
Cc: IETF working group on revision of mail standards <drums@cs.utk.edu>
Subject: RE: smtpupd-09 date errors
Date: Mon, 15 Mar 1999 09:46:52 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"

I disagree.  The RFC 822 date field, referring to Coordinated Universal
Time (UTC), is both an email standard and is emulated elsewhere.  (For
instance, although
<http://www.normos.org/ietf/draft/draft-newman-deliver-02.txt> uses a
delta time in seconds, it's likely that many RFC 821bis extensions will
use the Date definition in other ways.)  Changing from 4DIGIT to 4*DIGIT
costs nothing, is well-understood in its implications, and has at least
some small potential of being useful down the line.  It also brings
821bis into compatibility with 822bis, which defines:

year            =       ([FWS] 4*DIGIT [FWS]) / obs-year

I also believe there are 4 people who want to make the change (so it is
not out of order).  By contrast, I agree that all of your examples below
(sidereal time, etc.) are completely superfluous to the standard and
should not be considered.

For a perspective on why this could possibly matter, I'd recommend Danny
Hillis's thoughtful essay on the Clock of the Long Now.
<http://www.longnow.com/10kclock/clock.htm>

		- dan

-----Original Message-----
From: John C Klensin [mailto:klensin@MCI.NET]
Sent: Monday, 1999-03-15 09:29
To: Nathaniel Borenstein
Cc: IETF working group on revision of mail standards
Subject: Re: smtpupd-09 date errors


Nathaniel,

Let me repeat something I think I've said before: I have no 
problems at all changing the syntax to *4Digit from 4Digit 
if the WG wants that. But as Perry, and others, have 
pointed out, that doesn't solve any likely problems, it 
just creates a hook that permits us to feel self-righteous 
about it.

Note that the dates in smtpupd-09/-10 are strictly dates 
inserted contemporaneously in transport, so they cannot 
refer to future time.   My answers might be a little 
different were we talking about, e.g., a message expiration 
date in which it would be relevant to talk about something 
happening in the distant future.

But, for contemporaneous dates, I suggest that a "make the 
year longer" proposal is sufficiently incomplete as to not 
be worth worrying about.  A meaningful proposal would, IMO, 
need to address:

  -- Inserting into Date fields, in a canonical way (e.g., 
      not as a comment) a description/label of the calendar 
      system/base reference being used, at least when that 
      is different from "AD/CE Gregorian".

  -- In order to prevent interoperability messes, rules 
      about handling and designating current (not 10,000+) 
      dates relative to alternate calendar bases in use 
      today, e.g., non-Gregorian calendars (e.g., AH, AC 
      dates, potentially using non-solar calendars)

  -- And probably, while we are at it, sufficient tagging 
      to permit expressing Siderial and other alternate-to-
      24-hour-solar time systems, again, without ambiguity 
      of the need to supercomputers to be able to interpret 
      the date/time on a message into local reference time.

Such a proposal might or might not be in scope for DRUMS, 
but it certainly is not on the table.

        john

------

On Mon, 15 Mar 1999 09:56:26 -0500 (EST) "Nathaniel 
S. Borenstein" <nsb@si.umich.edu> wrote:

> I want to thank Jacob for coming up with a fairly compelling example
> here.  (As you may remember, I was unhappy with allowing a Y10K bug,
but
> hadn't come up with a good argument as to why it was important.)  Most
> code doesn't deal with nuclear waste storage, but if anyone is writing
> it today, they surely won't be around to fix the bugs in the year
> 10,000.  
> 
> For my part, I feel quite strongly that if we're going to have another
> "Y2K" type of event, it should be far enough in the future that it
can't
> threaten the health of our descendants.   Management of nuclear waste
is
> probably the most forward-looking example that really matters, so I
> would argue that our year fields should extend long enough for the
most
> toxic of such wastes to become relatively harmless.