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 [email protected] Would your name perchance be surname Puppet, given name Sock? --Rick Moen _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
