Subject: RE: smtpupd-09 date errors

From: Dan Kohn <[email-masked]>
Date: Mon, 15 Mar 1999 09:46:52 -0800

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:[email-masked]]
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" <[email-masked]> 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.

---

From: "Perry E. Metzger" <[email-masked]>
Date: 15 Mar 1999 13:20:31 -0500

Dan Kohn <[email-masked]> writes:
> Changing from 4DIGIT to 4*DIGIT
> some small potential of being useful down the line.

Gack.

This whole debate is silly. If (and only if) it in no way delays the
documents, I can support the change, since it is virtually
harmless. If it delays the documents in any way, however, I must
oppose the change, since it is virtually useless too.

(Anyone who believes it is not virtually useless is invited to
contemplate what date systems were in use 2000 years ago, let alone
8000 years ago.)

Perry

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Mar 1999 00:11:36 -0000

> contemplate what date systems were in use 2000 years ago, let alone

The basic 12-month calendar, identifying dates by year-month-day, was
established by Roman emperor Numa Pompilius more than 2500 years ago.
The Anno Domini epoch was defined about 1500 years ago.

History demonstrates increasing standardization of time-measurement
systems. It's entirely reasonable to predict that people in the year
10000 will still be labelling dates with years A.D., months, and days.

(There will be another correction in the leap-year schedule over the
next several thousand years. However, like the Julian and Gregorian
corrections, it won't affect the basic year-month-day format.)

---Dan

---

From: "Perry E. Metzger" <[email-masked]>
Date: 15 Mar 1999 19:29:55 -0500

> established by Roman emperor Numa Pompilius more than 2500 years ago.

And it did not standardize the lengths of months, or of the year for
that matter. It was not the current seasonally precise length until
far later. Furthermore, years qua years were not described as 
"year X" but "In the year of the Consuls X and Y". Furthermore, most
of the world was NOT following this calendar at the time, and
predicting that the Julian calendar would be essentially maintained
would have been very difficult. If, for example, the Muslims had
succeeded in conquering Europe, we might now be using a radically
different calendrical system. This was not an entirely foregone
conclusion.

However, the question is not one of whether we will be using the 12
month calendar in 10k years. The question is whether we will be using
current MUA and MTA standards and code in, not 1000, or even 2000
years, but in 8000 years. If we are still using our current standards
in 1000 years, I'll be shocked. In 8,000, I'd be completely
shocked. 8,000 years ago, humans didn't have WRITING.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 15 Mar 1999 19:42:04 -0500

Oh, and as long as I'm being pedantic...

> established by Roman emperor Numa Pompilius more than 2500 years ago.

There were no Roman Emperors until Augustus, about 2030 years
ago. Before that, there were Consuls who were elected, and a
considerable stretch before that, kings.

Perry

---

From: "Nathaniel S. Borenstein" <[email-masked]>
Date: Tue, 16 Mar 1999 08:44:41 -0500 (EST)

Perry Metzger wrote:

> Anyone who believes it is not virtually useless is invited to
> 8000 years ago.

There are basically two theories about the emergence of modern
technological culture.  One is that, like previous civilizations, ours
will flourish for a while and then fall.  The other is that we're in the
middle of a truly unique transition point in the history of life on
Earth, one that people will look back on, hundreds of thousands of years
from now, as the point at which sentient life crossed a quasi-permanent
threshold in its ability to control and direct its own environment.  

I tend to favor the latter view -- with the possibly dubious assumpton
that we won't foul our nest beyond repair in the interim.  If I'm
correct in this regard, then contemplation of the past 8000 years is not
a very useful guide in predicting the next 8000.  (I think this may be a
generalization of what Dan Bernstein meant when he said "History
demonstrates increasing standardization of time-measurement systems.")

> John Klensin wrote:

> just creates a hook that permits us to feel self-righteous 

I beg to differ.  I think the important thing we're doing here is
setting a highly visible precedent -- in the context of one of the
world's most open and thoughtful standards-setting bodies.  Any future
programmer will be hard-pressed to justify being MORE conservative than
the IETF.

The earliest programmers who had to deal with dates (circa 1950's)
jumped in and used 2-digit years, which quickly became normative.  We're
all paying for that now in the form of Y2K-mania, but there's also an
opportunity here -- we're at a unique moment in time when new *norms*
will be established for how programmers commonly represent dates.  I
think it's worthwhile trying to establish those norms in a
forward-looking way.  Thus I would argue that we would be performing a
long-term service for our descendants if we work to establish norms for
date representation that extend far enough into the future for the most
far-reaching human enterprises.  (In addition to nuclear waste
management, deep space probes also come to mind.)

I know this seems silly to many of you, but I'd encourage you to
consider that it's at worst harmless to plan far ahead, because our
predictions of the future are often ludicrously far from the mark.  When
I first read RFC 761 (TCP) in 1981, my initial reaction was that this
was very good stuff, but that the restriction of addresses to 32 bits
was a serious long-term mistake.    The people I mentioned this to
simply laughed -- there were, I think, fewer than 200 machines on the
net at that point -- and at the time I certainly didn't think it would
turn into a serious problem quite as soon as it did.  But *nothing* in
my career in computing has suggested to me that planning very far ahead
is EVER a bad idea.
--------
Never practice:  you can only      | Nathaniel Borenstein
practice mistakes.  Learning is    |  <[email-masked]>
always new.  -- Krishnamurti       | http://nsb.si.umich.edu/~nsb