On Tue, Jun 02, 2015 at 07:48:48AM -0700, Bill Unruh wrote: > It really would be nice if Mill's leap clock stop were really implimented > instead of the backward step the kernel does now (I had thought that it was > implimented. I was wrong)
If you are refering to the approach where the clock is "stopped" and is advanced only when something reads the clock, I think that would be difficult to implemented in modern kernels since the reading of the clock doesn't involve a system call and the kernel doesn't really know if there are any processes reading the clock. Anyway, I think a clock having a frequency error of 99.99% (running 10000x slower) would be more problematic for applications than 8.3% as for instance chrony uses in the slew mode by default. The interval where the clock is wrong would be only 12 times shorter (1.0001 second vs 12 seconds). > Alternatively the system clock uses TAI seconds, and the conversion to UTC > happened in the gettime software, since it already has to handle conversion to > YMDHMS anyway. Of course this would mean that ntp would need a flag to tell > that it was on TAI rather than UTC seconds or clients would again get > confused. NTP clients could convert UTC to TAI locally using system tzdata (e.g. with the right/UTC timezone). The problem is with applications that rely on the POSIX definition of system time where every day has 86400 seconds. The Linux kernel provides the CLOCK_TAI clock which doesn't have the backward step, but we can probably safely assume only a small minority of applications will be modified to use that. This whole problem with handling leap seconds is about breaking as few applications running on the system as possible. -- Miroslav Lichvar -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
