[LEAPSECS] Leap seconds still broken

There’s been lots of discussion about fixing kernels[1], application software, databases, etc etc to handle leap seconds properly. Meanwhile over in reality even the software that’s supposed to keep track of time basically still fails on leap seconds. Even some national standard time servers

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

Brooks Harris wrote: >accurate representation before this instant is explicitly out of scope. In that case, you should have no need to perform any conversions between time scales for times before 1972. Yet you insist on particular (incorrect) correspondences between time scales for such times.

Re: [LEAPSECS] Happy Leap Second alarm

Only two of our eight stratum-1 servers were accessible since the domes are in weather shutdown, but leap went nominally at this end. Will keep an eye on the others when they boot. Rob — > On Dec 31, 2016, at 5:13 PM, Steve Allen wrote: > > As expected, and right on time,

Re: [LEAPSECS] Greetings from an intercalary second

Line 55 of my raw headers has your leap second: 1 Return-Path: 2 Delivered-To: tvb-leapsecond:com-...@leapsecond.com 3 X-Envelope-To: t...@leapsecond.com 4 Received: (qmail 73506 invoked from network); 1 Jan 2017 00:00:09 - ... 00049 for

[LEAPSECS] Happy Leap Second alarm

As expected, and right on time, we got this alarm > Date: Sat, 31 Dec 2016 16:00:10 -0800 > Subject: APF: EOS Telescope (PMAC) clock error > > The difference between 'PMAC' and Unix time is now -0.993602, and has been >= > 0.050 for 10 seconds We will reboot the telescope control computer

Re: [LEAPSECS] Greetings from an intercalary second

I wrote: > Some readers may be interested in the Date: line on this message. I should have said: readers who are able to view the raw Date: line "on the wire". Any mail software which parses and redisplays the date (including that which archives this mailing list at pairlist6.pair.net) is likely

[LEAPSECS] Greetings from an intercalary second

Some readers may be interested in the Date: line on this message. It is not faked: it was added by a lightly-modified sendmail program running under a Linux kernel keeping true UTC, with the timestamp fetched via clock_gettime(CLOCK_UTC) and formatted using a timespec-aware version of localtime().

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

On 2016-12-31 01:21 AM, Zefram wrote: Brooks Harris wrote: There is a hole in the data of these tables; Rec 460 tells us the origin of TAI is "1 January 1958" but the first TAI-UTC value listed in the tables is in 1961 - what happened between 1958 and 1961? You've previously shown some

Re: [LEAPSECS] 2016 is not tied for second longest year ever

On Sat 2016-12-31T10:10:06 -0700, Warner Losh hath writ: > There's also other year reckonings for other cultures that produce > very long results depending on what you tag as "a year" Yes to all these editorials, so allow me to edit my original to 1904 was the second longest year ever *using the

Re: [LEAPSECS] 2016 is not tied for second longest year ever

On Sat, Dec 31, 2016 at 1:12 AM, Clive D.W. Feather wrote: > Warner Losh said: >> I'd think that 1712 in Sweeden was the longest year with 31708800 SI >> seconds (give or take a few hundred milliseconds, my data-sniffing fu >> isn't up the challenge of digging through the

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

On Sat, Dec 31, 2016 at 9:31 AM, Steve Summit wrote: > I'd like to say I'm not going to worry about that sort of case > too much -- clearly, we can't implement proper leap second > handling if we can't trust our time services to report them > properly! -- but based on what I'm

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

On Sat 2016-12-31T11:31:42 -0500, Steve Summit hath writ: > As Zefram already noted, Markus Kuhn specified CLOCK_UTC pretty clearly > at https://www.cl.cam.ac.uk/~mgk25/posix-clocks.html -- and that was > back in 1998! We have a lot of proposals for technical solutions. Klepczynski and Dennis

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

Warner Losh wrote: > On Sat, Dec 31, 2016 at 1:13 AM, Zefram wrote: > > You're prejudging the implementation too much. The kernel does need > > to know about each leap second by the time it happens, but it does not > > need to convert timer expirations between TAI and UTC

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

Warner Losh wrote: > On Fri, Dec 30, 2016 at 9:52 PM, Steve Summit wrote: > > CLOCK_TAI is already in the newest Linux kernels, but I'm not sure how > > well it works; CLOCK_UTC is, shall we say, emerging. > > Other systems don't have this quite yet, but I'd love to see it more

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

On Sat, Dec 31, 2016 at 1:13 AM, Zefram wrote: > Warner Losh wrote: >>Other systems don't have this quite yet, but I'd love to see it more >>widely implemented. Is there a spec for this yet, > > https://www.cl.cam.ac.uk/~mgk25/posix-clocks.html Cool, but last updated 1998...

Re: [LEAPSECS] POSIX?

On Dec 30, 2016, at 10:40 PM, Warner Losh wrote: > Nothing is ever re-written from scratch. Which includes vast amounts of scientific literature in which Universal Time corresponds to mean solar time at Greenwich. Nothing and nobody keep POSIX or ITU or BIPM from defining a

Re: [LEAPSECS] 2016 is not tied for second longest year ever

Warner Losh said: > I'd think that 1712 in Sweeden was the longest year with 31708800 SI > seconds (give or take a few hundred milliseconds, my data-sniffing fu > isn't up the challenge of digging through the historical data to find > out how many). That was a double-leap-year. What about 708

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

Warner Losh wrote: >Other systems don't have this quite yet, but I'd love to see it more >widely implemented. Is there a spec for this yet, https://www.cl.cam.ac.uk/~mgk25/posix-clocks.html >To do this, one would need to tell the kernel that a new leap second >is introduced. That's not too bad,