On Thu 2006-12-28T17:35:00 +0000, Tony Finch hath writ: > but still without enough complexity to deal with the whole problem. How > does your proposal deal with local time zone changes, e.g. "same time > tomorrow", or times based on weeks, e.g. "last thursday in the month"?
Problems with the Gregorian calendar are separate from problems with leap seconds, and long predate them. A completely historically accurate time interface for the calendar runs into similar chaos as trying to translate pre-atomic civil timestamps to instants of the IAU's Terrestrial Time (TT). Every locality had its own sources of time. Starting with the BIH in 1919 the problem is historically tractable becuase in their publications there are records of the differences in time values of those agencies who broadcast their time scales. As with much of history, outside of that the problem is intractable for lack of any documentation. The full past history of local variations in time or date are topics of special which are too much to expect to build into a generic timekeeping interface. One of the most challenging Gregorian calender problems is the date of the day after Thanksgiving in the US. Thanksgiving is the 4th Thursday in November. The day after is a Friday, but it is not necessarily the 4th Friday. For many agencies, however, it is a holiday. A working example of a computer-based calendar which could encode the date of that holiday was the original Tcl/Tk program "ical". http://en.wikipedia.org/wiki/Ical_%28Unix%29 This is not to be confused with the program now distributed with Apple's Mac OS X or with the standard that is codified by RFC 2445, but avoiding confusion is very hard because the name "ical" is associated with the original program, the RFC, and Apple's program. The original Tcl/Tk ical program is still runnable with some effort, but in practical use almost all current programs claim to conform to RFC 2445. I'm not sure, but I think that RFC 2445 was a result of efforts to standardize the capabilities found in ical. Although the examples given in RFC 2445 seem to indicate that it was intended to be able to encode such things, the implementations I have seen do not seem to be capable of doing that. Indeed, it seems that many of the snips of code in the newer ical files eschew the examples in the standard which are supposed to indicate how to represent a particular sort of date. What is worrisome here is that an international standards effort started with a working example and produced a document which is so convoluted that implementors have not only failed to reproduce the capabilities described in the standard, but they have also failed to reproduce the functionality of the original program. What is worrisome to me about changing the nature of UTC is that it entices implementors to try to encode all the past characteristics of some time scale or another. That is why I concur with the published results of the Torino conference: Create a a new time scale. Make it totally plain that it does not share characteristics with previous time scales so that implementors are not enticed to try proleptic interpretations. Make it clear that one size does not fit all, and that the new time scale is intended to solve a particular class of problems. -- Steve Allen <[EMAIL PROTECTED]> WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99858 University of California Voice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m