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 <sla_at_ucolick.org> 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
Received on Thu Dec 28 2006 - 11:31:15 PST