Subject: Re: smtpupd-09 date errors

From: John C Klensin <[email-masked]>
Date: Mon, 15 Mar 1999 12:29:21 -0500 (Eastern Standard Time)

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: "D. J. Bernstein" <[email-masked]>
Date: 15 Mar 1999 23:48:23 -0000

I used 4*DIGIT in my date-time syntax in April 1996 because that's how
BNF expresses ``an integer >= 1000.''

Someone responded that 4*DIGIT should be 4DIGIT. Elz explained that
4*DIGIT allows years beyond 9999. (``Now that is planning for the
future!'' he said.)

There wasn't any further discussion until November 1996, when Resnick
posted the first msg-fmt draft with 4DIGIT.

``Hmmm,'' I said. ``Didn't we agree on 4*DIGIT? :-)''

Resnick responded: ``Well, *I* thought it was a fine plan. :-) I don't
know why I forgot to put it in. I will if there is no other objection.''

``Good,'' I said. ``Let's not contribute to the Y10K problem. :-)''

And so msg-fmt was fixed with a minimum of fuss. It amazes me that
anyone would object to making the analogous fix in smtpupd.

John C Klensin writes:
> description/label of the calendar system/base reference being used,

This would be even more frivolous than time zones. I don't care about
your favorite time display format; that's something for you to work out
privately with your MUA.

trn, for example, automatically parses incoming dates and feeds them to
localtime(). This would be a much more common feature if the date format
weren't so badly engineered.

---Dan