Re: [r6rs-discuss] [Scheme-reports] Date and time arithmetic library proposal for R7RS large Scheme

[John Cowan <cowan@x>]

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  cowan@x  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
r6rs-discuss@x
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss