Re: [LEAPSECS] Time math libraries, UTC to TAI

Brooks Harris wrote: > It seems to me infeasible to alter the basic behavior of time_t > because it effects every aspect of the operating system, Absolutely. Posix time_t is untouchable, and here to stay. > POSIX time and 86400-second-day systems (including Windows time) will > never exactly

Re: [LEAPSECS] seconde intercalaire

The Ottawa Citizen is reporting that the outage there was not because the leap second was "unexpected", but was caused by a failed attempt to handle the leap second. http://ottawacitizen.com/news/local-news/leap-second-knocked-key-city-radios-offline-new-years-eve

Re: [LEAPSECS] Time math libraries, UTC to TAI

Hello Steve; Your computer must have a clock time error or teh network is extremely, extremely slow. The message timestamped 2017-01-04 20:39 was received at about 2017-01-05 16:57-05:00 -Stephen On 2017-01-04 20:39, Steve Summit wrote: Martin Burnicki wrote: If we don't look only at the

Re: [LEAPSECS] Time math libraries, UTC to TAI

Martin Burnicki wrote: > If we don't look only at the kernel and ntpd, but also consider PTP, > then there's still the question if if wouldn't be better to let the > kernel time run on TAI, and derive true and/or smeared UTC from it. Right. At first when I was trying to implement CLOCK_UTC, I

Re: [LEAPSECS] alternative to smearing

Warner wrote: > There's problem, and trying to equivocate away by saying "well, > if you just did it right it would be OK" isn't a helpful position. > Requiring every computer to do complicated things so that a leap > second can work once in a blue moon isn't a good engineering tradeoff. >

Re: [LEAPSECS] Time math libraries, UTC to TAI

Warner wrote: > On Wed, Jan 4, 2017 at 9:26 PM, Steve Summit wrote: > > Warner Losh wrote: > >> It then becomes an interesting question: do you have to back convert > >> form UTC to TAI when doing a stat on a file in this scheme? > > > > No, not at all. The timestamp in the

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

Re: [LEAPSECS] Time math libraries, UTC to TAI

Warner Losh wrote: |On Wed, Jan 4, 2017 at 9:26 PM, Steve Summit wrote: |> Warner Losh wrote: |>> On Wed, Jan 4, 2017 at 7:15 PM, Steve Summit wrote: |>>> 2. Have xtime keep TAI. This has the advantage that it's not at |>>>all

Re: [LEAPSECS] LEAPSECS Digest, Vol 124, Issue 17

And the name on the certificate could have been changed to 'Frederic' :-) Cheers to Gilbert & Sullivan! (in case anyone needs a hint) Richard On Thu, 5 Jan 2017, Tom Van Baak wrote: Feb 29th, of course. The print macro just adds "10" to the year field. :-) What would be worse is if Hal

Re: [LEAPSECS] alternative to smearing

On Thu, Jan 5, 2017 at 4:26 AM, Hal Murray wrote: > > [do something N years in the future] >> Except that's not how things are programmed. Programming it that way would >> be very inefficient in a part of the kernel that has to be ultra-efficient. >> Since you don't know

Re: [LEAPSECS] alternative to smearing

On Thu, Jan 5, 2017 at 3:42 AM, Hal Murray wrote: > >> 1) The leap day in February can be handled by any isolated or autonomous >> clock or timekeeping system. A leap second can only be handled with periodic >> direct or indirect communication with IERS, or manual

Re: [LEAPSECS] Time math libraries, UTC to TAI

Brooks Harris wrote: >I'm not understanding where you think there is an error. The last day of the Julian calendar was in reality, and necessarily, the day preceding the first day of the Gregorian calendar. The first day of the Gregorian calendar is accurately shown in the table as 1582-10-15,

Re: [LEAPSECS] seconde intercalaire

The London (England) Ambulance Service also suffered a problem just after midnight. I can't find any reports pinning the problem on the leap-second, but it seems too much of a coincidence not to be related. Peter On 5 January 2017 at 14:39, Tom Van Baak wrote: > An

Re: [LEAPSECS] Time math libraries, UTC to TAI

On 2017-01-04 09:15 PM, Steve Summit wrote: Martin Burnicki wrote: If we don't look only at the kernel and ntpd, but also consider PTP, then there's still the question if if wouldn't be better to let the kernel time run on TAI, and derive true and/or smeared UTC from it. Right. At first when

Re: [LEAPSECS] Time math libraries, UTC to TAI

On Wed, 2017-01-04 at 21:58 -0700, Warner Losh wrote: > But keeping the kernel time in TAI and reporting it in UTC still > doesn't solve the userland side of things because time goes backwards > across the leap second... If everything were in TAI and it was just a > conversion, then some math

[LEAPSECS] seconde intercalaire

An alert reader sent me this note. I have not independently confirmed it. /tvb On December 31, 2016, in Montreal Québec, the municipal police/FD radio communications went into a total shutdown for over 55 minutes. The $74 million digital-encrypted SERAM radio communications system

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

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

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

Re: [LEAPSECS] LEAPSECS Digest, Vol 124, Issue 17

> Feb 29th, of course. The print macro just adds "10" to the year field. :-) What would be worse is if Hal worked there 40 years before he got a 10th anniversary certificate. /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com

Re: [LEAPSECS] LEAPSECS Digest, Vol 124, Issue 17

On Thu, Jan 5, 2017 at 7:10 PM, Hal Murray wrote: > I started work at DEC on Feb 29th. 10 years later, I got a fancy > certificate > congratulating me on being there for 10 years. Want to guess what date was > on it? > Feb 29th, of course. The print macro just adds

Re: [LEAPSECS] Leap second smearing test results

Hal Murray wrote: > >>> I don't think the client pays any attention to that field in the packet. >> Hm, when Harlan made the proposal then he said the client did. > > You are right. There is some code in there. Thanks. > > It might be interesting to see what the RFC or book says about that

Re: [LEAPSECS] alternative to smearing

On 2017-01-05 06:26 AM, Hal Murray wrote: [do something N years in the future] Except that's not how things are programmed. Programming it that way would be very inefficient in a part of the kernel that has to be ultra-efficient. Since you don't know how many seconds it will from now, you can't

Re: [LEAPSECS] Leap second smearing test results

>> I don't think the client pays any attention to that field in the packet. > Hm, when Harlan made the proposal then he said the client did. You are right. There is some code in there. Thanks. It might be interesting to see what the RFC or book says about that area. I'd like to understand

Re: [LEAPSECS] alternative to smearing

On Thu, Jan 5, 2017 at 7:26 PM, Hal Murray wrote: > How far in advance were the last daylight savings changes announced? In the US, the Energy Policy Act of 2005 which changed onset of DST in Mar 2007, was enacted in Aug 2005, but this amount of notice is rare

Re: [LEAPSECS] LEAPSECS Digest, Vol 124, Issue 17

> I started work at DEC on Feb 29th. 10 years later, I got a fancy certificate > congratulating me on being there for 10 years. Want to guess what date was > on it? Ha! This from the same company that in 1983 wrote my favorite bug report of all time:

Re: [LEAPSECS] Time math libraries, UTC to TAI

On 2017-01-02 03:07 PM, Michael.Deckers. via LEAPSECS wrote: On 2017-01-02 18:55, Brooks Harris wrote about the correspondence | Date| MJD| NTP | NTP Timestamp | Epoch| | 4 Oct 1582 | -100,851 | -3 | 2,873,647,488 | Last day Julian | Ah, I

Re: [LEAPSECS] alternative to smearing

[do something N years in the future] > Except that's not how things are programmed. Programming it that way would > be very inefficient in a part of the kernel that has to be ultra-efficient. > Since you don't know how many seconds it will from now, you can't schedule a > timeout. The current

Re: [LEAPSECS] LEAPSECS Digest, Vol 124, Issue 17

> 9) Exposing citizens to leap days is near universal. Printed and computer > calendars have no trouble with that extra day. Almost every child learns > about leap years during their schooling. Some people are even born on a leap > day. I started work at DEC on Feb 29th. 10 years later, I got

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

Re: [LEAPSECS] alternative to smearing

> 1) The leap day in February can be handled by any isolated or autonomous > clock or timekeeping system. A leap second can only be handled with periodic > direct or indirect communication with IERS, or manual intervention with the > likes of keyboard input or toggle switches. For secure or

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

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

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