|
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? 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? /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 [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
