[r6rs-discuss] [Scheme-reports] Date and time arithmetic library proposal for R7RS large Scheme
cowan at mercury.ccil.org
Tue Nov 30 11:20:55 EST 2010
Ray Dillinger scripsit:
> If we're talking standards here we should just say "inexact real" and
> not worry about how particular implementations represent those.
I don't want to say "inexact", precisely because 64-bit floats are losing
precision all the time. I'll leave exact or inexact up to the implementor.
> It is reasonable IMO to require a time library to report the
> available precision.
Fair enough. On Posix systems the precision is 1 microsecond.
> In some circumstances a system clock can have a known inaccuracy,
> but I don't think it's reasonable to anticipate and report all the
> different forms that could take; one that I remember from a real
> system was days/hours/minutes/seconds driven by a low-granularity
> but accurate timer, with "fake microseconds" driven by a counter
> on the machine's instruction dispatch. All you could say about
> microseconds on that system was that a greater number meant a
> later time, and that the machine would "usually" count up to
> some "randomish" number between 600K and 700K microseconds
> before dropping back to zero at the start of the next second
> but "occasionally" the count might be as low as 400K or as high
> as 950K depending on what the machine was doing, because some
> instructions take fewer cycles than others.
Right. Some years ago, I was running Linux under VMware with a Windows
host, and at that time VMware and Linux interacted badly to make the
software clock run much too fast. In order to keep time-of-day reasonably
accurate, I set up a cron job to run once per minute that would grab the
time (to 1 second precision) from the Windows host using RFC 858 protocol
(port 37), with rdate(1) on the Linux side and some RFC 858 server,
I forget exactly what, on the Windows side. The result was that the
time was forcibly resynced 30-40 secondswards about 5-10 seconds after
the start of each minute, thus sacrificing monotonicity in favor of
long-term timekeeping. This had the potential to screw up make(1),
but I don't think it ever actually did.
There are three kinds of people in the world: John Cowan
those who can count, cowan at ccil.org
and those who can't.
More information about the r6rs-discuss