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

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

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 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

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

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

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

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

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

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

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

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

In the late 1960s German radio station DCF77 did not broadcast time signals 24 hours a day. Different agencies controlled different signals at different times of day. Deutsches Hydrographisches Institut broadcast signals based on old UTC using their measurements of UT2 and the BIH offsets. PTB

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

On Wed 2020-02-05T15:32:54-0800 Tom Van Baak hath writ: > I'm not sure it's fundamental to TAI that one must always, or only, use > 24x60x60 radix notation. That's a useful convention in many cases, but at > the h/w counter or s/w binary integer level radix notation is not required. There were

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

Warner, > Yes. I wish it were clearer that TAI time is a regular radio expression of time. > Here regular radix means that it every day has 24 hours and every hour 60 minutes > and every minute has 60 seconds. I'm not sure it's fundamental to TAI that one must always, or only, use 24x60x60

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

   On 2020-02-04 21:16, Steve Allen wrote: The first time that the 4th meeting of the CCDS happened was in 1966, but that meeting is not found in any official record. The meeting ended with a vote to recommend that the CGPM should adopt an SI second based on cesium, but the circumstances of

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

On Tue, Feb 4, 2020 at 7:31 AM Brooks Harris wrote: > On 2020-02-04 2:54 AM, Warner Losh wrote: > > > > Have I forgotten any of the other details of leap seconds that are > > more tribal knowledge than rigorously specified? > > > > Warner > > > > > I think another unclear topic is when the value

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

I have a growing bibliography with references that show the rush toward atomic time was already underway at the 3rd CCDS meeting in 1963. At that meeting the delegates restricted themselves merely to ask CGPM12 to authorize an atomic SI second before CGPM13. The first time that the 4th meeting

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

Tony Finch wrote: > The IERS Bulletins C state a value of UTC-TAI "until further notice". As I understand this, it just means that yet it's not known if and when another leap second will have to be scheduled. > However the machine-readable files from IERS and NIST give an expiry date > of a few

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

   On 2020-02-04 13:44, Tony Finch wrote: The IERS Bulletins C state a value of UTC-TAI "until further notice". However the machine-readable files from IERS and NIST give an expiry date of a few days less than 6 months after the announced (lack of) leap second, or a bit more than 11 months

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

On 2020-02-04 2:54 AM, Warner Losh wrote: Have I forgotten any of the other details of leap seconds that are more tribal knowledge than rigorously specified? Warner I think another unclear topic is when the value of DTAI ("The value of the difference TAI – UTC") is updated. This is not

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

Warner Losh wrote: > > Have I forgotten any of the other details of leap seconds that are more > tribal knowledge than rigorously specified? The IERS Bulletins C state a value of UTC-TAI "until further notice". However the machine-readable files from IERS and NIST give an expiry date of a few

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

On Mon, Feb 3, 2020, 6:01 PM Brooks Harris wrote: > On 2020-02-03 10:37 AM, Michael Deckers via LEAPSECS wrote: > > > > > >The 1970 report also contains the proposal that the CIPM should be > >responsible for the definition of UTC, and 49 years later, the CGPM > >in 2019 seems to

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

On 2020-02-03 10:37 AM, Michael Deckers via LEAPSECS wrote: The 1970 report also contains the proposal that the CIPM should be responsible for the definition of UTC, and 49 years later, the CGPM in 2019 seems to have taken on that task with the resolution

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

On 2020-02-02 22:30, Steve Allen wrote: On Sun 2020-02-02T17:59:20+ Michael Deckers hath writ: The maximum deviation |UTC - UT1| <= 0.9 s as stipulated in 1974 by CCIR Rec. 460-1 has never been violated until now. That violates the agreement that the difference between UTC and UT1 would

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

On Sun 2020-02-02T17:59:20+ Michael Deckers hath writ: > The maximum deviation |UTC - UT1| <= 0.9 s as stipulated in > 1974 by CCIR Rec. 460-1 has never been violated until now. That violates the agreement that the difference between UTC and UT1 would be encoded as part of the time

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

   On 2020-02-01 23:59, Steve Allen wrote: In every instance where a document specified a maximum deviation that agreement was later violated.    The maximum deviation |UTC - UT1| <= 0.9 s as stipulated in    1974 by CCIR Rec. 460-1 has never been violated until now. In one case it was

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

On Sun 2020-02-02T00:33:08+0100 Warner Losh hath writ: > It's the fact that things like filesystems > specify an elapsed time since an epoch in a time scale without leap > seconds. Every FAT or NTFS disk around has a time like this. Beginning 2018-06-01 the value of Microsoft Windows FILETIME

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

On Sat, Feb 1, 2020 at 10:57 PM Seaman, Robert Lewis - (rseaman) < rsea...@email.arizona.edu> wrote: > Tried to send this a few days ago, but it never showed up on the list. > Steve has provided gritty details since. > > > > Since roughly the second world war, the distinction between time-of-day