Date: Wed, 15 Dec 2010 12:09:47 +0200 From: Vitaly Magerya <[email protected]>
In short, as long as UTC is the basis of civil time keeping, TAI will not solve any problems. A UTC clock ticks seconds on exactly the same intervals that a TAI clock does. Whether you say SECONDS-SINCE-UTC-EPOCH returns the number of UTC clock seconds since the UTC epoch or the number of TAI clock seconds since the UTC epoch makes no difference. It's the POSIX clock that's wrong. [1] To be clear on this, NTP does not transmit current UTC-TAI difference by default. There is in fact "tai" field in ntptimeval, but it is only updated by ntpd if it has a leap seconds table.... Not quite. Within 86400 seconds before a leap second, an NTP server raises a flag alerting clients of the pending leap second. At the start of the leap second, the NTP's wire format for times shifts by one second, and simultaneously the flag lowers. Clients can thereby see a smooth view of TAI/UTC time. Linux, NetBSD, and FreeBSD all have a variable time_tai that is incremented at the moment the leap second ends and the POSIX clock is set back by a second. The userland can request the value of time_tai through ntp_gettime (BSD) or adjtimex/ntp_adjtime (Linux). Programs can thereby see a smooth view of TAI/UTC time. (Putting any calendrical logic (e.g., leap seconds) in the kernel's timekeeping is asinine, of course, but traditional.) time_tai is initialized correctly only if the userland (e.g., the ntpd) initializes it correctly with ntp_adjtime. But if it is not initialized thus, you will still see a smooth view of TAI/UTC time. At worst, your calendar may display dates that are off by up to half a minute. Do you care? Probably not. If you did, you would have told your system about the historical leap second table. Why do we care about a smooth view of TAI/UTC time and not just `monotonic time'? Because two different computers can agree on the UTC epoch but not on a boot-time epoch for a monotonic clock. _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
