On 2020-02-06 9:08 AM, Warner Losh wrote:


On Thu, Feb 6, 2020, 3:22 AM Tom Van Baak <t...@leapsecond.com <mailto:t...@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@leapsecond.com <mailto:LEAPSECS@leapsecond.com>
    https://pairlist6.pair.net/mailman/listinfo/leapsecs



_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Reply via email to