On Thu, Jan 5, 2017 at 4:39 PM, Carlos E. R.
My read is that the kernel has the leap second (hard/soft)coded into it somewhere. After all, the time function has to be able to do time counting calculations taking into account all the historic variations of the clock.
I don't think the kernel needs this information or even knows about leap seconds. When using ntp, the kernel just does what it is told. ntp decides how to change the time. The info that tells that a leap second is soon to happen lets ntp update that change in a possibly different way than how it handles normal jitter. How ntp does this is configured.
But my read of the logs disproves this theory. My kernel did know about the leap second, and it was the kernel who informed ntp, not the other way round.
The leap seconds are builtin inside the kernel.
Maybe there is a kernel call made by ntp that does this?
This can be proved by running an isolated test machine without ntp, and setting the time on it to Dec 31th, see what happens in the log. My bet is it adds the leap second.
Interesting test. I think it will not add the leap second. It may also interact with the setting that tells if the hardware clock is UTC. Things like daylight savings time changes only seem to be done when the hardware clock is set to UTC.
One more question: at 00:00 local or UTC?
I think 00:00 UTC time. The full message was: 2017-01-01T00:59:59.001885+01:00 acme kernel: [1438619.838798] Clock: inserting leap second 23:59:60 UTC My system changed the time at 00:59:59.001885 local time, which is 23:59:60 [sic] UTC So the second must be inserted at the same instance everywhere: 23:59:60 UTC, no matter the local time. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org