[plt-scheme] Time Base

The easiest thing to see immediately is that (date-nanosecond
(current-date)) always returns a value smaller than 10,000,000, which is 100
times to small. Try the following which returns the minimum and maximum such
values - it takes a while because of the random sleeps.

(for/fold ((minimum +inf.0)
           (maximum -inf.0))
          ((i (in-range 1000)))
  (let ((nanosecond (date-nanosecond (current-date))))
    (sleep (/ (random) 10.0))
    (values (min nanosecond minimum) (max nanosecond maximum))))

You'll get something like:

0.0
9840000.0

as a result when they should run between 0 and 999990000 (for 100
millisecond accuracy). So, they don't fail any range checks, they're just
1/100 of the proper value.

If you look at the code for SRFI 19, there are many places where
milliseconds is multiplied by 10000 to get results that are later used as
nanoseconds, which is 100 times too small. But, it would take some going
through the code to sort it all out. My assumption is that something got
crossed between the 100 millisecond accuracy (from POSIX and common in OS
time calculations, including those used by PLT Scheme) and the millisecond
to nanosecond calculations, but it's just a guess.

Doug

On Tue, Dec 15, 2009 at 3:24 PM, John Clements <clements at brinckerhoff.org>wrote:

>
> On Dec 15, 2009, at 1:20 PM, Doug Williams wrote:
>
> > The data/time routines in PLT Scheme have many warning about using the
> actual values for current-seconds, etc directly and about the base time that
> is used. At least on Windows and Linux (Ubuntu 9.10 in this case),
> current-inexact-milliseconds seems to return the number of milliseconds
> since  00:00:00.000 1 Jan 1970. Is this the case for all systems.
> >
> > I am implementing RFC 4122 (UUIDs) and need a good time implementation. I
> was using SRFI 19, but it turns out to be problematic. The reference
> implementation, which is pretty much what is in PLT Scheme, has errors - in
> particular, the nanoseconds calculations are off by a factor of 100 and it
> ripples through some of the other calculations and the author has withdrawn
> support. There are patches around for some of these problem in other Scheme
> implementations, but I haven't tracked them all down (or checked the PLT
> Scheme bug list). And, I really don't need all that SRFI 19 provides.
>
> Just between us, the SRFI-19 implementation is dreadful.  Don't tell anyone
> I said that.  Especially not anyone else on the plt-scheme mailing list.
>
> More seriously: it sounds like you're in a position to contribute a couple
> of (failing) test cases.  Even though you're not going to be using the
> library, others could potentially benefit from your knowledge, if you're
> willing to share.
>
> Many thanks,
>
> John Clements
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20091215/52ee49e9/attachment.html>