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

Thomas Bushnell, BSG scripsit:

> So what I heard was that you wanted to represent an instant of time as
> an integer, with some determinate resolution, and then the predictable
> fight about whether the integer should be denominated in milliseconds,
> microseconds, or nanoseconds.

Not at all. My proposal allows instants to be either exact or inexact
rationals. The question is, if you add 1 to a instant, do you get an
instant one second later (modulo leap seconds), or 1 ms later, or what?
This is neither accuracy, precision, nor resolution, but a fourth notion
which I will call scaling. When instants are integers, scaling and
resolution are the same thing, but not so when instants are allowed to
be non-integers.

Scaling is good: it says how much "1" is. But it has nothing to do with "resolution".

Stop thinking about "integers". Integers are irrelevant; these are real numbers and the fact that some of them are integers is irrelevant.

If the interface says "number of seconds since the epoch, not counting leap seconds" (which is what Posix's gettimeofday is), then let it be that. "Add 1" to the value means "add one second". The precision is about the precision of the particular numeric representation. The accuracy is a question of the system clock underneath, which is interesting to know but not determinable with Posix.

So the interface should return seconds (naturally, since that's what Posix thinks in), and should promise to return a real number.

Marc Feeley's arguments persuaded me to require inexact rationals as
the representation of instants. However, in practice these are 64-bit
floats, which means since the resolution varies with the distance of
the instant from the epoch, we currently (41 years after the epoch) can
get approximately 10^-5 resolution at best if an instant is a 64-bit
float, and it will get worse as time goes on. So I have removed the
recommendation to use inexact numbers.

Remember to separate the exactness of a numeric representation from the accuracy of the underlying clock. If the accuracy is 10ms (typical for lots of systems), then that does not mean it's pointless for the numeric representation to be exact. So I agree that there should be no recommendation about what sort of numeric format to use. Keep in mind that "inexact rational" does not mean "floating point" in Scheme.

Most clocks don't know their accuracy at all, never mind knowing their
accuracy accurately.

I think we should have a interface for it, but alas, Linux and Posix don't provide a way to get it. Given NTP and the granularity of clock interrupts, the accuracy is known in some sense to the system as a whole, but in practice difficult to determine.

Thomas