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

2017-01-09 Thread Brooks Harris
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

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

2017-01-08 Thread Brooks Harris
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

2017-01-08 Thread Martin Burnicki
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

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

2017-01-08 Thread Martin Burnicki
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

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

2017-01-07 Thread Tony Finch
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

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

2017-01-07 Thread John Sauter
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)

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

2017-01-07 Thread Zefram
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

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

2017-01-07 Thread Brooks Harris
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

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

2017-01-06 Thread Hal Murray
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

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

2017-01-06 Thread Brooks Harris
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

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

2017-01-06 Thread Zefram
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

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

2017-01-06 Thread Martin Burnicki
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

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

2017-01-06 Thread Martin Burnicki
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

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

2017-01-05 Thread Steffen Nurpmeso
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

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

2017-01-05 Thread Brooks Harris
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

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

2017-01-05 Thread Tony Finch
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

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

2017-01-05 Thread Martin Burnicki
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 >>

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

2017-01-05 Thread Tony Finch
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

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

2017-01-05 Thread Martin Burnicki
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

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

2017-01-05 Thread Martin Burnicki
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

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

2017-01-04 Thread Tony Finch
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

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

2017-01-04 Thread Steffen Nurpmeso
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

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

2017-01-04 Thread Steffen Nurpmeso
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

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

2017-01-04 Thread Martin Burnicki
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.

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

2017-01-04 Thread Michael.Deckers. via LEAPSECS
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, but most implementations are broken

2017-01-04 Thread Martin Burnicki
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

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

2017-01-04 Thread Martin Burnicki
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

2017-01-04 Thread Martin Burnicki
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

2017-01-04 Thread Martin Burnicki
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

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

2017-01-03 Thread Steve Summit
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

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

2017-01-03 Thread Ask Bjørn Hansen
> 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

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

2017-01-03 Thread Steve Allen
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

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

2017-01-03 Thread Tony Finch
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