On 2015-01-12, brian utterback <brian.utterb...@oracle.com> wrote: > > On 1/11/2015 10:40 PM, William Unruh wrote: >> On 2015-01-12, Mike S <mi...@flatsurface.com> wrote: >>> On 1/11/2015 7:16 PM, William Unruh wrote: >>>> If that public source is responsible it will pass on to your >>>> system the fact that there is a leapsecond, and your system will "stop" >>>> for a second at the last second of June. >>> A system which properly implements leap seconds will do no such thing. >>> It will properly account for a minute with 61 seconds, and will tick >>> from 23:59:59 to 23:59:60 then to 00:00:00. >>> >>> There is no "stopping," or any other discontinuity. >> Well, actually as I understand it, ntpd does stop the cclock for that >> second, making sure that every successive read of the clock during that >> time is later than the one before by a few microseconds. until the >> second ends. >> > > That is not the case. That is the behavior that the kernel reference
I presume the "That" refers to ntpd. I will accept that it is the Linux kernel does that. I also admit I do not know how windows impliments leap seconds. > code implements which is not part of ntpd. It is up to the individual OS > leap second implementers to determine the behavior they implemented, > which may or may not behave this way. But if you do not do that then ntpd will, after a while, jump the time (since the time to do 1 sec at 500PPM would be 2000 sec, or about an hour. Of course it would have to first decide that the clock was out by a second. AGain, I do not know how Windows handles it, but it is ntpd which does the jumping in that case. Ie, there could well be a discontinuity. > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
