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

Terje Mathisen terje.mathisen at tmsw.no
Wed Jan 14 15:01:03 UTC 2015


Jochen Bern wrote:
> On 01/13/2015 09:33 AM, Terje Mathisen wrote:
>> I hate to admit it, but I'm starting to believe Google's approach, where
>> they smear the leap second over something like a day, [...]
>>
>> For distributed logging you have to use the same method for every single
>> node, but that is the case today as well. :-(
>>
>> I.e. with one domain smearing and another stepping, the times between
>> them will be skewed over the entire smearing period.
>
> I've been pondering this some more. Isn't the consequence that, for the
> purposes of the NTP protocol, "Googleish" and "non-Googleish" systems
> are *fundamentally incompatible* on the day of the leap?

Oh, absolutely!

Nobody should ever be allowed to observe/compare time stamps from google 
and non-google systems taken at any point during the smear period.

Since Google is lying, they must be responsible for making sure that no 
such timing info ever leaks out.

Terje
>
> As in, when ntpd looks across that divide, there'll be an apparent
> offset in the tenths-of-seconds range for the better part of a day,
> which is long enough that ntpd *will* take corrective action (in a
> default config, a step) on the client side, and thus completely hose the
> client OSes' attempt at dealing with the leap second according to its
> native procedure?
>
> Shouldn't it be a *requirement* that, however an OS chooses to implement
> a leap second, it must keep the timeframe in which its local clock is
> (likely to be) off the true timescale short enough to not confuse
> timesyncing protocols (with the obvious exception of discrete hard
> syncs, a.k.a. SNTP)?
>
> Regards,
> 								J. Bern
>


-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



More information about the questions mailing list