Ray Dillinger scripsit: > The major [disadvantage of recognizing leap seconds] is that we cannot > get the local time corresponding to a numbered second more than a year > in the future, nor the numbered second corresponding to a specified > date and time more than a year in the future.
We can't anyway, because local time is subject to change at the whim of political bodies. In Israel, for example, the DST rules are changed every year, and it's typical for tzdata (the time zone data of the tz database) to have 5-10 releases a year as things change around the world. Indeed, in principle a leap second can occur at the end of *any* month, and there is historical precedent for having more than one in a single year. The crappy clock of the Earth is running slow right now, so we haven't had many lately, but the long-term trend is inexorable. > This is because fundamentally it's not well predictable - we can't > know in advance which years the astronomical union will declare > as containing an additional leap second. The only "reasonable" > way to deal with it seems to be assuming that future years will > be exactly 86400 seconds long but it will not, in fact, turn out > to be the case. I agree. > So if you're going to use the cesium second, you > wind up needing either formatted-dates or the notion of the > planetary-rotation second anyway if you want to specify a > particular time on a particular date in the future as opposed > to a particular number of seconds into the future. Right, and clocks and calendars run on planetary-rotation seconds. > Which "second" is preferable depends on the application. As I have said, errors of one part in 10^-8 are more than you can expect out of computer clocks anyhow; 10^-4 to 10^-5 is the state of the art. -- John Cowan [email protected] http://ccil.org/~cowan The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. --Edsger Dijkstra _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
