[LEAPSECS] Leap seconds have a larger context than POSIX

[Brooks Harris]

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 
> <mailto: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.
>
>     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.
-Brooks
>
> 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 <mailto:LEAPSECS at leapsecond.com>
>     https://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/25077ede/attachment.html>