In message <199612312318.PAA02746@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@fh-jena.de> mailed me on 1995-09-12. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn@cs.purdue.edu