Subject: smtpupd-09 date errors

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Jan 1999 15:14:34 -0000

> second of the minute in the range 00 to 59,

This prohibits leap seconds.

> YYYY = 4*4Digit

This prohibits years past 9999.

---Dan

---

From: Tony Hansen <[email-masked]>
Date: Fri, 29 Jan 1999 12:52:08 -0500

> This prohibits leap seconds.

I agree with Dan on this one. The number should at least be allowed to
range up to 60. Modern computer systems WILL potentially generate such a
number when leap seconds occur, so it would behoove us to permit it
within the standard.

Note that the man page for ctime() on most unix systems has the
following

    struct tm {
	int tm_sec;	/* seconds after the minute - [0, 61] */
				/* for leap seconds */

I don't know if UTC would ever allow the number of leap seconds to be
two, giving a legal value of 61, but it wouldn't hurt for us to match
the man page and also allow the value of 61.

	Tony Hansen
	[email-masked]

---

From: "Perry E. Metzger" <[email-masked]>
Date: 29 Jan 1999 12:57:53 -0500

> This prohibits years past 9999.

I, for one, am terrified.

Perry

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 29 Jan 1999 10:42:40 -0800

>number when leap seconds occur, so it would behoove us to permit it

I agree with Tony and Dan on this. Many Unixes might indeed generate a 60
during a leap second.

I do not agree with Dan's objection to YYYY, unless it was an attempt to be
humorous, in which case I do agree with it, because it made me laugh.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Dave Sill <[email-masked]>
Date: Fri, 29 Jan 1999 14:04:54 -0500 (EST)

Paul Hoffman / IMC <[email-masked]> wrote:
>I agree with Tony and Dan on this.

Me four.

>humorous, in which case I do agree with it, because it made me laugh.

It's too soon to worry about Y10K, but it's not too soon to start
thinking in terms of removing unnecessary limits.

-Dave

---

From: "Perry E. Metzger" <[email-masked]>
Date: 29 Jan 1999 14:19:46 -0500

> I agree with Tony and Dan on this. Many Unixes might indeed generate a 60

Yeah, I have to admit -- this field *should* range from 0-60, not to
59. It is such a minor change I don't see why it can't go in.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 29 Jan 1999 14:23:08 -0500

> thinking in terms of removing unnecessary limits.

It is much easier to parse the field as is. As for "unnecessary
limits", well, eight thousand years ago, writing hadn't been invented
yet.

The odds that we will be using these formats in eighty years are
small. The odds that we will be using them in EIGHT THOUSAND YEARS are 
zero.

Perry

---

From: "Nathaniel S. Borenstein" <[email-masked]>
Date: Sat, 30 Jan 1999 10:07:59 -0500 (EST)

Excerpts from bulk.interesting.lists: 29-Jan-99 Re: smtpupd-09 date
errors @piermont.com (610*)

> small. The odds that we will be using them in EIGHT THOUSAND YEARS are 

For the record -- not that either one of us will be around to see who's
right -- I disagree.  I think the odds are greater than zero, and that
any unnecessary limit on digits in years is regrettable.
--------
It is a characteristic of wisdom      | Nathaniel Borenstein
not to do desperate things.           |  <[email-masked]>
    -- Henry David Thoreau            | http://nsb.si.umich.edu/~nsb

---

From: John C Klensin <[email-masked]>
Date: Sat, 30 Jan 1999 10:46:12 -0500 (Eastern Standard Time)

On Sat, 30 Jan 1999 10:07:59 -0500 (EST) "Nathaniel S. 

> any unnecessary limit on digits in years is regrettable.

Nathaniel,

Speaking personally, I found myself initially sympathetic to
this, and was about to look at whether the syntax could easily
be changed to permit a four-or-longer digit year.  Whether that
would be wise or not is a short-term issue: I'd guess that at
least some existing implementations would respond badly to a
five (or more) digit year, and I'd be hard-pressed to argue that
this is important enough to justify blowing them up in the short
term.

But there is another issue: While the odds are low (but not
zero) that we will be using these formats in eight thousand
years, I think the odds are yet lower that we will be using the
same calendar system, more or less exclusively.  There is a
"Gregorian" implied in the existing date format and "stardates"
or "mars standard time" are likely to change a lot more than the
zone offset.  If one ignores the practicalities of
implementations for the moment, slipping an additional "calendar
system" token into the date would be fairly hard (and a late
incompatible change from a procedural standpoint).

Oddly, what I think this does is to make a case for a strictly
four-digit year, maybe with an explicit MUST NOT provision on
anything longer.  That would give us the ability, if needed some
years out, to extend the system by making the rule that a "year"
of five digits or longer must be accompanied by some additonal
syntax that identified the date/time system in some standardized
way.

   john

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Jan 1999 18:12:56 -0000

Perry E. Metzger writes:
> It is much easier to parse the field as is.

No. If you care about the Y10K problem, the old format is simply wrong.
If you don't care, you can use exactly the same parsing code either way.

Note that msg-fmt already allows 5-digit years at my request.

---Dan