[LEAPSECS] Leap seconds have a larger context than POSIX

[Warner Losh]

On Thu, Feb 6, 2020 at 7:17 AM Brooks Harris <brooks at edlmax.com> wrote:

> On 2020-02-06 9:08 AM, Warner Losh wrote:
>
>
>
> On Thu, Feb 6, 2020, 3:22 AM Tom Van Baak <tvb at leapsecond.com> wrote:
>
>> Hi Hal,
>>
>> It's 2020. How on earth can NTP still not implement UTC correctly, in all
>> cases? Or is it a fundamental NTP design flaw?
>>
>
> Design flaw. NTP time stamps can't encode a leap second. It can therefore
> never really work in all cases. We are left with what hack do you want to
> do today.
>
> You can't fit 86401 pegs in 86400 holes. Something's got to go. No
> agreement on what goes.
>

Exactly. We have a number of different hacks that we use to keep the
problems under control, to discard potentially bad data, to filter bad data
that we can't discard, etc. It's a series of hacks that usually work well.
Not because it's well specified, but because different implementations have
programmed defensively to ensure that the current spec + unwritten policy
rules + some known past bugs are filtered so ntpd doesn't react when it's
likely a bad time. This will fail, of course, if we ever have a leap second
in March or September. It's working for the conditions we have today, which
is great, but it's not robust or resilient.

> The Z3801A issue doesn't sound like an NTP problem. This is a known legacy
>> Z3801A f/w or Motorola Oncore problem, yes? Maybe also affected by one or
>> even two GPS WNRO problems buy now?
>>
> Known past issues are likely future problems. 40 years in software has
> taught me that we do not always learn and apply the lessons of the past.
> Every 5-10 years we swap out the coders that learned them for newer,
> cheaper labor. Or there are new players in a niche that have more hubris
> than tribal knowledge. This guarantees bugs will repeat.
>
> Especially in the absence of clear specifications.
>

Yes. That's exactly what I meant by tribal knowledge. We could all tell
long stories about how we learned all the details because of that absence...

Warner


> Warner
>
>
> /tvb
>>
>> On 2/6/2020 1:41 AM, Hal Murray wrote:
>>
>> tvb said:
>>
>> There's no ambiguity. Those are just bugs. No software should depend on  more
>> than 1 month notice of a leap second and no software should be  fooled if the
>> notice is months or even years in advance.
>>
>> There are plenty of quirks in ntp code along that line.  The APIs don't have
>> an explicit when.  The NTP-Kernal API for leap-pending is leap-tonight.  You
>> have most of the next day to turn it off.  The leap-pending on the wire is
>> leap-at-the-end-of-this-month.
>>
>> I fixed a bug in the Z3801 driver by ignoring a leap pending unless it was
>> June or December.  It's a hack, but it gets the job done and the code wasn't
>> setup to ask it when the leap would happen.
>>
>>
>> tvb said:
>>
>> If you're writing a FAQ or best practices guide stay in touch. I have a
>> semi-technical leap second report in the works. UTC is actually very  simple;
>> but it's been complicated by untold levels of bad assumptions,  bad
>> execution, and bad prose.
>>
>> Are you going to say anything about POSIX?
>>
>>
>>
>>
>> _______________________________________________
>> LEAPSECS mailing list
>> LEAPSECS at leapsecond.com
>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>>
>
>
> _______________________________________________
> LEAPSECS mailing listLEAPSECS at leapsecond.comhttps://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20200206/e4cc3666/attachment.html>