Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

As I said, Windows is huge and evolving, and Sever is different from regular Windows versions; be careful when mixing and matching versions. Some of these technotes are pretty recent, like 2014 or 2015. See - How to configure an authoritative time server in Windows Server https://support.micros

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

On 2017-01-08 10:15 AM, Martin Burnicki wrote: Brooks Harris wrote: On 2017-01-06 11:52 AM, Martin Burnicki wrote: - OS kernels with different features (Windows doesn't even know leap seconds, AFAIK) It is often repeated on LEAPSECS that "Windows doesn't even know leap seconds". That's just

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Zefram wrote: > To be clear: obviously knowledge of the upcoming leap second must come > from some external source. A system with such advance knowledge is then > able to apply that knowledge at the proper time, maintaining a correct > clock through the leap second, without any further external co

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Brooks Harris wrote: > On 2017-01-06 11:52 AM, Martin Burnicki wrote: >> >>> >>> - OS kernels with different features (Windows doesn't even know leap >>> seconds, AFAIK) >>> >>> > > It is often repeated on LEAPSECS that "Windows doesn't even know leap > seconds". That's just not true. It knows ver

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Hal Murray wrote: > > Anybody know when NTP supported it's first leap second? I think RFC 958 (Sept 1985) was the first NTP RFC, and it includes support for leap seconds. The earlier network time RFC's lack leap seconds. I don't know at what point after RFC 778 (April 1981) NTP learned about them

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

John Sauter wrote: >"How any changes to the value of seconds since the >Epoch are made to align to a desired relationship with the current >actual time is implementation-defined. As represented in seconds since >the Epoch, each and every day shall be accounted for by exactly 86400 >

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

On Sat, 2017-01-07 at 10:56 +, Zefram wrote: > > No, the Gregorian calendar is yet another thing that doesn't imply > 86400-second days.  (POSIX time_t is another.)  There's a general > pattern > here that whenever there's some construct that counts or labels days, > and is (as most are) silen

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Brooks Harris wrote: >That would indeed be a smart computer. If it can divine the next Leap Second >without need to consult an external source, To be clear: obviously knowledge of the upcoming leap second must come from some external source. A system with such advance knowledge is then able to ap

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

On 2017-01-07 02:50 AM, Hal Murray wrote: leapsecs-requ...@leapsecond.com said: Right, that's where I say its incredible nothing was done since 1972. The Leap Second history is fundamental, and it seems to me an obvious missing link. How could it have gone ignored all this time? Back in the o

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

On 2017-01-06 05:33 PM, Zefram wrote: Brooks Harris wrote: It is often repeated on LEAPSECS that "Windows doesn't even know leap seconds". That's just not true. It knows very well about Leap Seconds in the same way other systems do but it (typical desktop versions) is lazy about when it updates

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

leapsecs-requ...@leapsecond.com said: > Right, that's where I say its incredible nothing was done since 1972. The > Leap Second history is fundamental, and it seems to me an obvious missing > link. How could it have gone ignored all this time? Back in the old days, computer clocks weren't accu

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

On 2017-01-06 11:33 AM, Martin Burnicki wrote: Brooks Harris wrote: On 2017-01-05 05:56 AM, Tony Finch wrote: Martin Burnicki wrote: Please note that NTP servers not necessarily need to be providers for leap second files. There are some well known sites which provide this file, and the NTP so

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Brooks Harris wrote: >It is often repeated on LEAPSECS that "Windows doesn't even know leap >seconds". That's just not true. It knows very well about Leap Seconds in the >same way other systems do but it (typical desktop versions) is lazy about >when it updates No, what it does doesn't involve kno

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

On 2017-01-06 11:52 AM, Martin Burnicki wrote: - OS kernels with different features (Windows doesn't even know leap seconds, AFAIK) It is often repeated on LEAPSECS that "Windows doesn't even know leap seconds". That's just not true. It knows very well about Leap Seconds in the same way

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Steffen Nurpmeso wrote: > Martin Burnicki wrote: > |Yes, and there needs to be an interface to timekeeping software in > |general, i.e. provide glibc and friends with updated tz rules, and make > |the leapsecond table available in a form that can be used by ntpd or ptpd. > | > |In case of ntp

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Brooks Harris wrote: > On 2017-01-05 05:56 AM, Tony Finch wrote: >> Martin Burnicki wrote: >>> Please note that NTP servers not necessarily need to be providers for >>> leap second files. There are some well known sites which provide this >>> file, and the NTP software package from ntp.org comes w

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Martin Burnicki wrote: |Steffen Nurpmeso wrote: |> Martin Burnicki wrote: |>|Ask Bjørn Hansen wrote: |>|> [1] As much as I dislike the leap seconds; smearing is only appropriate |>|> if you specifically have chosen it so they␦re not supposed to be in the |>|> pool. |>| |>|Agreed. Smearing

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Martin Burnicki wrote: |Steffen Nurpmeso wrote: |> Martin Burnicki wrote: |>|Steve Summit wrote: |>|> Tony Finch wrote: |>|>> Even though NTP can represent current UTC correctly, it often \ |>|>> gets leap |>|>> seconds wrong. It does not give confidence that we will be able to |>|>> redu

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

On 2017-01-05 05:56 AM, Tony Finch wrote: Martin Burnicki wrote: Please note that NTP servers not necessarily need to be providers for leap second files. There are some well known sites which provide this file, and the NTP software package from ntp.org comes with a script which can be used to u

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Martin Burnicki wrote: > > If upstream servers aren't aware of the leap second and don't insert it, > then our server will see that its time is off by 1 sec after it has > (correctly) inserted the leap second. So a few minutes after the leap > second our server will step its time to match the time

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Tony Finch wrote: > Martin Burnicki wrote: >> >> Please note that NTP servers not necessarily need to be providers for >> leap second files. There are some well known sites which provide this >> file, and the NTP software package from ntp.org comes with a script >> which can be used to update the

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Martin Burnicki wrote: > > Please note that NTP servers not necessarily need to be providers for > leap second files. There are some well known sites which provide this > file, and the NTP software package from ntp.org comes with a script > which can be used to update the file automatically. I wa

Re: [LEAPSECS] Leap seconds ain't broken

Michael Shields via LEAPSECS wrote: > On Wed, Jan 4, 2017 at 1:46 AM, Martin Burnicki > wrote: >> I agree it would be good to implement this in an extension field, but >> generally care should be taken not to break compatibility. I mean, how >> do existing clients act if they receive a packet with

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Tony Finch wrote: > Martin Burnicki wrote: >> Tony Finch wrote: >>> >>> Even though NTP can represent current UTC correctly, it often gets leap >>> seconds wrong. It does not give confidence that we will be able to >>> reduce bugs by teaching more code about leap seconds, when NTP cares >>> about

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Steffen Nurpmeso wrote: > Martin Burnicki wrote: > |Ask Bjørn Hansen wrote: > |> [1] As much as I dislike the leap seconds; smearing is only appropriate > |> if you specifically have chosen it so they␦re not supposed to be in the > |> pool. > | > |Agreed. Smearing in the way it is currently

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Steffen Nurpmeso wrote: > Martin Burnicki wrote: > |Steve Summit wrote: > |> Tony Finch wrote: > |>> Even though NTP can represent current UTC correctly, it often gets leap > |>> seconds wrong. It does not give confidence that we will be able to > |>> reduce bugs by teaching more code about l

Re: [LEAPSECS] Leap seconds ain't broken

On Wed, Jan 4, 2017 at 1:46 AM, Martin Burnicki wrote: > I agree it would be good to implement this in an extension field, but > generally care should be taken not to break compatibility. I mean, how > do existing clients act if they receive a packet with unknown extension > field? Do they just ig

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Martin Burnicki wrote: > Tony Finch wrote: > > > > Even though NTP can represent current UTC correctly, it often gets leap > > seconds wrong. It does not give confidence that we will be able to > > reduce bugs by teaching more code about leap seconds, when NTP cares > > about time and gets it wron

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Martin Burnicki wrote: |Steve Summit wrote: |> Tony Finch wrote: |>> Even though NTP can represent current UTC correctly, it often gets leap |>> seconds wrong. It does not give confidence that we will be able to |>> reduce bugs by teaching more code about leap seconds, when NTP cares |>> abo

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Martin Burnicki wrote: |Ask Bjørn Hansen wrote: |> [1] As much as I dislike the leap seconds; smearing is only appropriate |> if you specifically have chosen it so they␦re not supposed to be in the |> pool. | |Agreed. Smearing in the way it is currently done by some Google servers |(and ntp

Re: [LEAPSECS] Leap seconds ain't broken

Warner Losh wrote: > That rather sums up the situation today with software. We have a > specific legacy standard called POSIX that's causing all kinds of > issues that pop up when you least expect it (taking out DNS server, > that's impressive), but there's no heir apparent to the standard, > and n

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Michael.Deckers. via LEAPSECS wrote: >Why doesn't the NTP message include the TAI - UTC offset used for >the UTC timestamp in the message? Even a faultily configured server >knows when it changes this offset, and it could help avoid the >interpretation of incorrect warning bits. I

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

On 2017-01-04 09:03, Martin Burnicki wrote: I think this you statement isn't quite fair. If a web server delivered a page with broken HTML code you wouldn't blame the web server daemon, e.g. apache, would you? It's the task of the web server admin to configure the server correctly and make

Re: [LEAPSECS] Leap seconds ain't broken

Steve Summit wrote: > It'd be nice to extend NTP with some kind of "provenance" field > which could say that a certain server is delivering smeared time. In fact ntpd also even does so. While smearing is in affect the "refid" field sent in replies to clients is set to "254.aa.bb.cc", where "aa.bb.

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Tony Finch wrote: > It's pretty embarrassing that one of our main time distribution > systems routinely screws up leap seconds. And it's even more embarrassing that the maintainers of such an important piece of network infrastructure don't get more support from vendors, even big ones which have h

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Steve Summit wrote: > Tony Finch wrote: >> Even though NTP can represent current UTC correctly, it often gets leap >> seconds wrong. It does not give confidence that we will be able to >> reduce bugs by teaching more code about leap seconds, when NTP cares >> about time and gets it wrong, and most

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Ask Bjørn Hansen wrote: > [1] As much as I dislike the leap seconds; smearing is only appropriate > if you specifically have chosen it so they’re not supposed to be in the > pool. Agreed. Smearing in the way it is currently done by some Google servers (and ntpd, if configured accordingly) is just

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Tony Finch wrote: > Warner Losh wrote: >> We have a >> specific legacy standard called POSIX that's causing all kinds of >> issues that pop up when you least expect it > > I haven't mentioned the usual litany of NTP servers getting it wrong, > including servers run by national time labs. It's pre

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Tony Finch wrote: > Even though NTP can represent current UTC correctly, it often gets leap > seconds wrong. It does not give confidence that we will be able to > reduce bugs by teaching more code about leap seconds, when NTP cares > about time and gets it wrong, and most code cares much less. I f

Re: [LEAPSECS] Leap seconds ain't broken

Hal Murray wrote: >> Since RFC 5905 describes new, tagged, extended fields for the NTP >> protocol, this sort of extra information should be very easy to add. > > Nope. It's the same old problem. There is lots of existing installed gear > that doesn't know about the new fields. Sure, but in th

Re: [LEAPSECS] Leap seconds ain't broken

> Since RFC 5905 describes new, tagged, extended fields for the NTP protocol, > this sort of extra information should be very easy to add. Nope. It's the same old problem. There is lots of existing installed gear that doesn't know about the new fields. Updating protocols with a large install

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

> On Jan 3, 2017, at 9:56 AM, Steve Allen wrote: > > Also not completely surprising was that we saw one of the pool.ntp.org > > servers (not Google) in use by our machines was clearly making a leap > smear available. You were pretty lucky then. It was only about 9 server

Re: [LEAPSECS] Leap seconds ain't broken

Tom Van Baak wrote: > That reminds me. I don't suppose we could get google, et al. to > rename it UTX instead of UTC? On a related note, there's the issue of knowing/confirming what kind of time an NTP server is giving you. (Stephen Colebourne was asking about this last month, too.) It'd be nice

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

On Tue 2017-01-03T17:46:34 +, Tony Finch hath writ: > I haven't mentioned the usual litany of NTP servers getting it wrong, Also not completely surprising was that we saw one of the pool.ntp.org servers (not Google) in use by our machines was clearly making a leap smear available. -- Steve Al

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Warner Losh wrote: > We have a > specific legacy standard called POSIX that's causing all kinds of > issues that pop up when you least expect it I haven't mentioned the usual litany of NTP servers getting it wrong, including servers run by national time labs. It's pretty embarrassing that

Re: [LEAPSECS] Leap seconds ain't broken

On Tue, Jan 3, 2017 at 6:35 AM, Rob Seaman wrote: > And Steve is discussing a specific legacy telescope. That rather sums up the situation today with software. We have a specific legacy standard called POSIX that's causing all kinds of issues that pop up when you least expect it (taking out DNS s

Re: [LEAPSECS] Leap seconds ain't broken

> There are subtleties to timekeeping. Removing leap seconds wouldn’t remove > the subtleties, rather it would promote them to significantly more > importance, perhaps “breaking” even more software and systems. > > Rob Now that several dominate vendors of computing are using smeared leap secon

[LEAPSECS] Leap seconds ain't broken

Hi Tony, > Come on, some of the rest of you must have seen some failure reports, > beyond just having to reboot your telescopes :-) To be clear, our telescopes were powered down for winter storms. And Steve is discussing a specific legacy telescope. Other telescopes I’ve been associated with ha