Re: [LEAPSECS] Leap seconds have a larger context than POSIX

On Wed, Feb 05, 2020 at 03:32:54PM -0800, Tom Van Baak wrote: > Code should allow for a leap second event at the end of any month. The June > / December thing is one of several guidelines for BIPM; it's not a rule that > anyone writing UTC code should assume or depend on. Nor should code ever >

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

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

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

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

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

Hello all, The fundamental answer / constraint to all questions of engineering, including temporal engineering, is funding. No bucks, no Buck Rogers. “Time” is a vast topic, pretty much as big as “space”. Precision timekeeping topics are only somewhat smaller in practical terms since issues of

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

Tom Van Baak 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? A program like ntpd (or ptpd, FWIW) has to rely on available sources of information, and if those sources provide wrong information, this

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

On 2020-02-06 5:22 AM, Tom Van Baak 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? The Z3801A issue doesn't sound like an NTP problem. This is a known legacy Z3801A f/w or Motorola Oncore problem, yes?

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

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. Please keep in mind that e.g. GPS sends out leap second

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

On Thu, Feb 6, 2020, 3:22 AM Tom Van Baak 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.

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

On Thu, Feb 6, 2020 at 7:17 AM Brooks Harris wrote: > On 2020-02-06 9:08 AM, Warner Losh wrote: > > > > On Thu, Feb 6, 2020, 3:22 AM Tom Van Baak 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?

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

Seaman, Robert Lewis - (rseaman) wrote: [...] > We are extremely happy with the quality and support we have received > from Meinberg, ... Thanks, Rob, I'm very happy to hear this. [...] > (I have no financial interests in Meinberg or NTF.) Disclaimer: ;-) Even though I'm working for Meinberg,

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

On 2020-02-06 9:08 AM, Warner Losh wrote: On Thu, Feb 6, 2020, 3:22 AM Tom Van Baak > 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

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

On 2020-02-06 7:28 AM, Seaman, Robert Lewis - (rseaman) wrote: Hello all, The fundamental answer / constraint to all questions of engineering, including temporal engineering, is funding. No bucks, no Buck Rogers. "Time" is a vast topic, pretty much as big as "space". Precision timekeeping