[r6rs-discuss] [Scheme-reports] Date and time arithmetic library proposal for R7RS large Scheme
bear at sonic.net
Sat Nov 27 21:17:17 EST 2010
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
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.
More information about the r6rs-discuss