On 2017-01-05 16:14, Roger Oberholtzer wrote:
On Thu, Jan 5, 2017 at 3:44 PM, Carlos E. R.
wrote: On 2017-01-05 10:11, Per Jessen wrote:
Carlos E. R. wrote:
ntp log has this:
31 Dec 02:38:57 ntpd[1749]: kernel reports leap second insertion scheduled 1 Jan 01:03:31 ntpd[1749]: kernel reports leap second has occurred 1 Jan 01:03:31 ntpd[1749]: kernel reports leap second has occurred
So ntpd is told by the kernel what is going to happen, 22 hours before.
That does not make much sense - unless the kernel had been told in advance. The messages above are reports on ntp_timeadj() return codes when ntpd attempts to adjust time.
In my server, it is obvious that is what happened:
Jan 01 00:59:59 Isengard kernel: Clock: inserting leap second 23:59:60 UTC
(the kernel reports that it inserts...)
And the ntp log confirms:
31 Dec 02:38:57 ntpd[1749]: kernel reports leap second insertion scheduled 1 Jan 01:03:31 ntpd[1749]: kernel reports leap second has occurred 1 Jan 01:03:31 ntpd[1749]: kernel reports leap second has occurred
About 22 hours before, the kernel tells the ntpd daemon that it is going to insert a leap second, and later it says that the kernel did in fact insert it, but at 01:03:31 - it could be that ntp log is using GPT time, not local time.
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. 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.
This is sort of what my original question was addressing: who adds the leap seconds? gpsd or ntp/chrony or the kernel?
Does NTP have the leap seconds built in? Or does the ntp packet tell this? I think that is the case. The reason that the packet from the server should contain this info is that the client must get this correct if it is started after that last leap second has happened.
The bigger mystery to me is strptime(3), which must be able to convert seconds to/from a date, and the date can be any one in the Unix epoch or even the future. How does it know if ntp applied the leap seconds when maintaining kernel time from which the date was derived? I think it uses a database for the timezone to decide when leap seconds have happened. But if your database is not up-to-date? And if the leap seconds were not used when the date was obtained?
One more question: at 00:00 local or UTC?
The pity is that this is not done differently: that minute should have 61 seconds. It is now impossible when seeing a timestamp 00:59:59 to know if it is the first time or the second time.
:60 cannot be represented. So what happens is that the time is changed from something like :59 to :58. Resulting in one additional second needed.
Why do you say that :60 can not be represented? It can, in computers, if the clock is programmed in software to handle it. Wall clocks can not. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)