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 <div class="gmail_quote">On Tue, Dec 15, 2009 at 3:24 PM, John Clements <<a href="mailto:clements@brinckerhoff.org">clements@brinckerhoff.org</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im"> 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. </div>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 </blockquote></div>