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

[John Cowan <cowan@x>]

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@x
and those who can't.

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