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

[Ray Dillinger <bear@x>]

On Sat, 2010-11-27 at 12:05 -0500, Marc Feeley wrote:
> On 2010-11-26, at 9:00 PM, John Cowan wrote:
> 
> > Marc Feeley scripsit:
> > 
> >> Please don't count time using milliseconds.  It clutters my brain to
> >> have to remember a different unit of time than plain seconds.
> > 
> > And yet the SI unit of mass is the kilogram.  But I'll think about that.
> 
> I'm not sure why you bring kilograms into the discussion.  We're talking about time and the SI unit for time is the second.

FWIW, I agree that the unit of time should be seconds, and that it
should be counted with a limited-precision "real" number.  I am 
perfectly happy to get milliseconds, etc, as non-integer real 
numbers. I am also reasonably willing to allow implementations 
to provide clocks that are no more accurate or precise than the 
system clock on the local computer.   

But then we get to hard questions about the specifics of what 
"seconds" that number does represent or ought to represent. 

Probably the biggest issue is do we or don't we want to ignore leap 
seconds?  

If we treat each day of the proleptic gregorian calendar as 
being exactly 86400 seconds, we ignore the "cesium" standard 
for the SI second and treat it effectively as a unit of 
planetary angular rotation instead. The upside is that it's 
pretty simple to deal with for programs.  The downside is that 
some seconds are longer than others. 

If we treat the cesium standard as the preferred unit for seconds, 
then we are true to the SI standard for seconds, but there are two 
downsides.  The minor one is that we have to do a table lookup and
addition to get the local date/time corresponding to a particular 
numbered second in the past or vice versa.  The major one 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.  

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. So you have to convert the planetary-rotation 
second in the future into a formatted date and time, and then 
handle conversions back to absolute seconds on the fly (much) 
later when leap-second data for the intervening years becomes available.
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.

Which "second" is preferable depends on the application. 

				Bear








_______________________________________________
r6rs-discuss mailing list
r6rs-discuss@x
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss