Martin,
Thanks you for using plain ASCII, which I can read much more easily than
the formatted version.
Let's face it, the version you are using has a bug, since corrected in
ntp-dev. Dirty rotten gmtime() numbers the days of the month from zero,
not one. I can verify here that the kernel does get the ntp_adjtime()
update on the correct month and day and does the right thing. I don't
have the test setup you have to actually verify the intended behavior.
Please report.
Dave
Martin Burnicki wrote:
Dave,
David L. Mills wrote:
Martin,
No fair on the bug, which has been there probably most of the seven
years since the last leap.
Can you tell your radio to step UTC at the same time the system kernel
implements it after being so advised by ntpd?
Yes. The device is not really a radio clock but it behaves like one.
It starts to count time at a predefined date, then announces the leap second
before it occurs, and inserts the leap second correctly.
I think you misunderstand how the kernel implements the leap. The ntpd
does not implement the leap; the kernel does. The kernel does not step
the clock. Please see the white paper "The NTP Timescale and Leap
Seconds" on the NTP project page for a detailed explanation.
I haven't looked at the project pages right now, but as far as I remenber
ntpd passes the leap second announcement to the kernel (if the kernel
supports it, unlike e.g. Windows), and the kernel inserts the leap second
at the right time.
This is how it has worked 5 days ago but didn't work now with the latest
patches.
Martin
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
