[time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Martin Burnicki martin.burnicki at burnicki.net
Wed Jul 20 05:04:03 EDT 2016


Hal Murray wrote:
> gem at rellim.com said:
>>> I don't think there is anything in the core of ntpd that restricts
>>> leap seconds to Jun/Dec.  If there was, it would have filtered out
>>> the above problem.
>> How about this: 
>> ntpd/refclock_hpgps.c, line 544:
> 
> I wasn't considering refclocks to be "core" in that context.  Got a better 
> word?
> 
> Have you found any similar code that isn't in one of the refclocks?

ntpd versions before 4.2.6 also had a plausibilty check, which even had
a bug when checking for end of June. See:
http://bugs.ntp.org/show_bug.cgi?id=525#c0

> gem at rellim.com said:
>> 20 years?  My house is 40 years old.  In an IoT world people would like to
>> not throw away capital equipment every decade. 
> 
> Your house gets a new roof occasionally.  The IoT world hasn't figured out 
> how to handle firmware updates and/or people haven't adapted to throwing out 
> gear that looks OK physically but has bugs, especially if the bugs don't 
> break the main function of the device.

Firmware updates? Why would anyone need this? ;-))

> gem at rellim.com said:
>> gpsd filters out all but June and December.  So sort of cleanly, but clearly
>> work needed.  ...
> 
> The sort of "cleanly" I had in mind would be at the project management level. 
>  Handwave.  Each project should keep track of the assumptions in their code 
> that may not be correct many years in the future.  That list should be 
> reviewed occasionally, say every year or few years.

Agreed.

> It also has to be documented in a way that downstream users know what they 
> are getting involved with.  This is a good example.  Tom is arguing for 
> do-it-right according to the specs.  I'm arguing for defensive programming 
> since we have already seen bugs in other gear.

I'd say the best solution would be a combination of both.

> If you were packaging ntpd 
> into a box which would you want?  Will your box last long enough to see a 
> leap second in Mar or Sep?  Is your box going to connect to old/buggy gear?  
> Does your startup have enough funding to consider issues like this, or people 
> smart enough to understand the tangle?

+1

Martin



More information about the time-nuts mailing list