[ntp:questions] Leap second to be introduced in June

William Unruh unruh at invalid.ca
Wed Jan 14 04:46:11 UTC 2015

On 2015-01-14, Phil W Lee <phil at lee-family.me.uk> wrote:
> brian utterback <brian.utterback at oracle.com> considered Mon, 12 Jan
> 2015 04:29:21 GMT the perfect time to write:
>>On 1/11/2015 4:56 PM, Rob wrote:
>>> Michael Moroney <moroney at world.std.spaamtrap.com> wrote:
>>>> If I have a system synchronized with a public NTP source, which is 
>>>> synchronized with an atomic clock that provides leap second info, and
>>>> I am watching carefully, what will happen when the leap second hits?  Will
>>>> my system suddenly find its clock off by 1 second and slowly drift to
>>>> the accurate time provided by the NTP server?
>>> That depends on what kind of system it is.
>>> Carefully designed systems will do the right thing.
>>Define "the right thing".
>>To eloaborate, there is no "right thing". There are a whole bunch of
>>"things" that are right for some people and not for others. That is the
>>very reason that there isn't a right thing, because if there was one
>>right thing all the vendors would have fixed their operating systems to
>>do it.
> As I understood it, there is a right thing (have a second spanning
> 23:59:60 to 00:00:00) but almost no software (or even the time
> libraries used in any of the common languages) groks it, so different
> systems use different fudges to work around it.

That is a translation from seconds to ymdhms. The problem is not there.
it is in the UTC seconds.
In UTC one second disappears after the leap second, but not before or
during. Thus UTC seconds numbering is simply disconinuous (jumps back) .
And it is that which is the problem, not the common name 
Thus one has 1435733999 then a second later 1435734000 then .9 seconds
later 1435734000.9 and .1 seconds later 1435734000.0

It is that discontinuity in the utc seconds that causes the trouble.
Mill's solution is to simply "stop" the clock during that extra second,
so, 1.9 sec after 1435733999 it will be 1435734000.000001 and .1 sec
later it will be 1435734000.000002. Whatever you do you have to loose
that second. (Ie he stops time except every time the clock is queried it
makes sure that it is later than the time before by a minimal amount. )
HOw you display it in normal language is of course up to
Now you could have the computer run in TAI and then do the translation
in userland software. But of course since most things expect utc
seconds, every call to the clock would require you figuring out what the
offset from utc to tai is, and subtract that number, making time system calls
much slower. 

More information about the questions mailing list