Date: Thu, 16 Dec 2010 16:36:50 -0800 From: Ray Dillinger <[email protected]>
In practice, on machines with POSIX time available, there is no error in any interval which does not include the midnight following June 30 or December 31 in any year. Therein lies the danger. 99.999998% of the time, your POSIX clock appears to behave well. Stress tests of your networked system show that it is robust to random clock errors. You put the system into production, and it runs without a hitch for two years. Random hardware clock failures in individual nodes with probability much greater than .000002% are handled gracefully by the network as a whole. Then, during a leap second, every node *simultaneously* observes an erratic clock. Would you like to be on call on New Year's -- nay, at New Year's Second -- to clean up the mess? I propose that you implement SECONDS-SINCE-UTC-EPOCH by calling ntp_gettime (or adjtimex/ntp_adjtime on Linux) and computing the formula ntptimeval.time.tv_sec + ntptimeval.tai - 10 + 63072000 (or timex.time.tv_sec + timex.tai - 10 + 63072000 on Linux). ntptimeval.time represents the POSIX time. ntptimeval.tai represents the current TAI - UTC offset, which is stored in the kernel's time_tai variable. Thus, ntptimeval.tai - 10 gives the number of leap seconds, because 1972-01-01T00:00:00Z was 1972-01-01 at 00:00:10 in TAI. If your kernel is informed of a pending leap second, then at the end of the leap second, it will simultaneously increment ntptimeval.tai and rewind the clock, i.e. hold ntptimeval.time.tv_sec fixed for a second. Thus, the formula I gave will increment normally at the leap second: it represents a well-behaved clock. If your kernel is not informed of a pending leap second, then at the end of the leap second, it will increment ntptimeval.time.tv_sec normally while holding ntptimeval.tai fixed. Thus, the formula I gave will increment normally at the leap second: it represents a well-behaved clock. What if your kernel's time_tai is not set by the operator or by the ntpd on boot, so that it uses a default `TAI - UTC offset' of 0? The formula I gave still represents a well-behaved clock. Your node might refuse to talk with peers whose clocks appear a few seconds off from yours, because their time_tai values are correct. But this problem manifests immediately and is easily remediable by the operator. Your calendars might be off by a few seconds. But do you care? Probably not. If you did, you would have set time_tai correctly. _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
