comments on draft-newman-datetime-00.txt

[Markus G. Kuhn]

In message <199612312318.PAA02746 at shade.twinsun.com>, Paul Eggert wrote:

> <URL:ftp://ds.internic.net/internet-drafts/draft-newman-datetime-00.txt>

I agree with Paul's remarks except where noted below.

> Section 4.2
> 
>   When the local offset is unknown, the offset "-00:00" MAY be used to
>   indicate that the time is in UTC and the local offset is unknown.
> 
> This is worded a little confusingly -- could you please clarify?
> Is it common to have situations where UTC is known but local time isn't?
> Without more motivation, it's hard to see why this suggestion is needed.

On board a plane, in orbit, in a submarine, in any mobile
device that receives time only by GPS or NTP, in my labtop that I carry
with me during my next south pole tour, ...

Since we can expect e.g., GSM cellular phones, LEO sat based phones, etc.
that include a tiny keyboard and allow you to write e-mail whereever
you are currently traveling, it is a not unrealistic assumption, that
the device that submits your e-mail knows UTC, but not your local time.

> ISO 8601 provides no way to represent years before the year 0000, or
> after the year 9999.  This makes it difficult to represent timestamps
> in some historical applications.  To fix this, you might extend the
> syntax for date-fullyear to:
> 
> 	date-fullyear = ["-"] 4*DIGIT
>
> where the years are numbered ..., -0002, -0001, 0000, 0001, 0002, ....
> (Note that unlike the traditional Julian calendar, there is a year 0
> in the modern Gregorian calendar.)

I think, this is definitely outside the scope of this draft. Remember: This
draft specifies a date+time format with at least second precision. This
is hardly something you would ever use for historic applications, where
you often want to be able to represent that you only know the date but
not the time, etc.  The authors of applications you are talking about should
look at the full ISO 8601 family of formats and not at draft-newman-datetime.
In this draft, we have in mind timestamps for digital objects (e-mail, etc.)
and not anything suitable to represent the time when some comet
appeared >3000 years ago. The same argument applies to the 2-digit year
conversion discussion: Birthdates will never be represented in the 
draft-newman-datetime format, because births are usually not recorded with 
second precision.

(BTW: my recorded birth timestamp was 1971-01-01 10:11+01, so I really had
to become a computer geek with these many 0s and 1s on the birth
certificate ;-).

However, I agree that ISO 8601 really should be extended by a specification
of how negative dates and dates >9999 can be represented. But this
is an issue for the ISO WG and not for a RFC. There are many other
things which could be added to ISO 8601, for instance there is no
distinguished notation for a MJD date and time, etc.

> Appendix B
> 
> I don't see why this section is needed, since this draft RFC doesn't
> care about the day of the week.  But if you think it's needed, here's
> the canonical reference for Zeller's congruence (written in German):
> 
> 	Chr. Zeller, Kalender-Formeln, Acta Mathematica, Vol. 9, Nov. 1886
> 

It is probably a good idea to provide a general small list of references for
calendar algorithms, as the readers of this standard are quite likely
to have to implement algorithms like determine weeknumber, weekday, MDJ,
difference in days between two dates, etc.

One good reference might be (haven't checked it myself yet):

      Dershowitz & Reingold
      Calendrical Calculation
      Software Practice and Experience vol 20#9 & vol 23 #4
      <URL:http://emr.cs.uiuc.edu/~reingold/calendars.html>

Contains many algorithms in Lisp for converting between calendars,
determining holidays all over the world, etc.

They's also published a more detailed book version:

      Calendrical Calculations 
      By Nachum Dershowitz and Edward M. Reingold. 
      Cambridge University Press, 1997.
      ISBN 0-521-56413-1 (Hardback) 
      ISBN 0-521-56474-3 (Paperback) 

Other references, some of which might also be worth being checked-out and
mentioned:

      Efficient timestamp input and output
      Dyreson & Snodgrass
      SWP&E vol 24 #1, Jan 94, pp89-109

      Larsen: Computing the Day of the Week
      DDJ, April 1995, pp125-126

      Meyer: Julian and Gregorian Calandars
      DDJ, March 1993

      In Ian Oliver, Programming Classics, Prentice-Hall 93, siehe chapter 3.2,
      pp.57-66.

Credit: Some of this is taken from a list of date/time algorithm references
that Prof. Karl Kleine <kleine at fh-jena.de> mailed me on 1995-09-12.

Markus

-- 
Markus G. Kuhn, Computer Science grad student, Purdue
University, Indiana, USA -- email: kuhn at cs.purdue.edu