Taylor R Campbell scripsit:

> The proposal claims that `there is about a 1 in 10^-8 probability that
> a computation of elapsed time made by calling this procedure twice
> will be off by 1.'  This langauge suggests that there is some random
> chance involved here.  But there isn't: leap seconds aren't drawn
> uniformly at random from time.  Instead, in a network of POSIX agents
> with reasonably accurate and well-synchronized clocks, every agent
> will observe an erratic clock simultaneously, once every few years.

I have removed this paragraph.

The real point of the 10^-8 is that an interval clock cannot keep the
difference between Posix and UTC time unless it is at least that
accurate, which is very improbable.

> Programs dealing with timing, rather than with calendars, don't care
> about leap seconds.  Giving them a clock corrupted by subtracting the
> number of leap seconds either breaks natural assumptions badly or
> requires extra work to cover up the corruption.  Either way, it wastes
> operator and programmer time, costs program complexity, and adds code
> paths that are hit dangerously seldom, only once every few years.

I have now added `current-jiffy` for elapsed time.

--
John Cowan              http://www.ccil.org/~cowan      cowan@ccil.org
Would your name perchance be surname Puppet, given name Sock?
                --Rick Moen

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports