Re: Leap Second planned for 2016

2016-07-10 Thread Jimmy Hess
On Sun, Jul 10, 2016 at 3:27 AM, Saku Ytti wrote: [snip] > a) use UTC or unix time, and accept that code is broken [snip] The Unix time format might be an unsuitable time representation for applications which require clock precision or time precision within a few seconds for the

Falsehoods programmers believe about time, etc (was Re: Leap Second planned for 2016)

2016-07-10 Thread Jay R. Ashworth
- Original Message - > From: "Chris Adams" > Once upon a time, Patrick W. Gilmore said: >> But time _DOES_ flow. The seconds count >> 58, 59, 60, 00, 01, … >> If you can’t keep up, that’s not UTC’s fault. [ ... ] > Leap second handling code is

Re: Leap Second planned for 2016

2016-07-10 Thread Jay R. Ashworth
- Original Message - > From: "Andrew Gallo" > Looks like we'll have another second in 2016: > http://www.space.com/33361-leap-second-2016-atomic-clocks.html "5... 4... 3... 2... 1... Zero!... Happy New Year!" But only if you're in London. 7pm EDT. Cheers, -- jr

Re: Leap Second planned for 2016

2016-07-10 Thread Mikael Abrahamsson
On Sun, 10 Jul 2016, Saku Ytti wrote: On 10 July 2016 at 00:12, wrote: It doesn't help that the POSIX standard doesn't represent leap seconds anyplace, so any elapsed time calculation that crosses a leap second is guaranteed to be wrong So how can we solve the

Re: Leap Second planned for 2016

2016-07-10 Thread Steve Allen
On Sun 2016-07-10T11:27:33 +0300, Saku Ytti hath writ: > So how can we solve the problem? Immediately and long term? The ITU-R had the question of leap seconds on their agenda for 14 years and did not come up with an answer. Their 2015 decision was to drop the question and ask an alphabet soup

Re: Leap Second planned for 2016

2016-07-10 Thread Saku Ytti
On 10 July 2016 at 00:12, wrote: > It doesn't help that the POSIX standard doesn't represent leap seconds > anyplace, so any elapsed time calculation that crosses a leap second > is guaranteed to be wrong So how can we solve the problem? Immediately and long term?

RE: Leap Second planned for 2016

2016-07-09 Thread Keith Medcalf
to keep it in sync with POSIX/Unix (normal) time. > -Original Message- > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of > valdis.kletni...@vt.edu > Sent: Saturday, 9 July, 2016 15:12 > To: Saku Ytti > Cc: NANOG list > Subject: Re: Leap Second planned for 20

Re: Leap Second planned for 2016

2016-07-09 Thread Valdis . Kletnieks
On Sat, 09 Jul 2016 12:14:03 +0300, Saku Ytti said: > Check the implementation on your PC. This is why code is broken and > people don't even know it's broken. You have to use monotonic time to > measure passage of time, which is not particularly easy to do > portable, in some languages. It

Re: Leap Second planned for 2016

2016-07-09 Thread Saku Ytti
On 9 July 2016 at 22:09, wrote: > well, we've gone through a few of these now...so if it was all okay before > its likely to be again... exception: any NEW code that > you are running since last time - THAT hasnt been tested ;-) In most cases the bugs are not

Re: Leap Second planned for 2016

2016-07-09 Thread A . L . M . Buxey
Hi, > Leap second handling code is not well-tested and is an ultimate corner > case. There's been debate about abolishing leap seconds; with all the well, we've gone through a few of these now...so if it was all okay before its likely to be again... exception: any NEW code that you are running

Re: Leap Second planned for 2016

2016-07-09 Thread Saku Ytti
On 9 July 2016 at 04:39, Patrick W. Gilmore wrote: Hey, > But time _DOES_ flow. The seconds count > 58, 59, 60, 00, 01, … > If you can’t keep up, that’s not UTC’s fault. Check the implementation on your PC. This is why code is broken and people don't even know it's

Re: Leap Second planned for 2016

2016-07-09 Thread Eric S. Raymond
Chris Adams : > Leap seconds are inserted to keep the atomic clocks synced with an > arbitrary time base (that is guaranteed to vary forever). There's > nothing magic about having noon UTC meaning the Sun is directly over 0° > longitude; if we didn't insert leap seconds, it

Re: Leap Second planned for 2016

2016-07-08 Thread Chris Adams
Once upon a time, Javier J said: > Unless you are running something that can't handle leap seconds what do you > really need to prepare for? The last several leap seconds have exposed weird and hard to predict bugs in various bits of software. Those previous bugs

Re: Leap Second planned for 2016

2016-07-08 Thread Chris Adams
Once upon a time, Patrick W. Gilmore said: > But time _DOES_ flow. The seconds count > 58, 59, 60, 00, 01, … > If you can’t keep up, that’s not UTC’s fault. Here in the real world of modern computers, virtually everybody has copied the UNIX/C behavior that doesn't

Re: Leap Second planned for 2016

2016-07-08 Thread Patrick W. Gilmore
On Jul 8, 2016, at 7:47 PM, Saku Ytti wrote: > On 9 July 2016 at 02:27, Jared Mauch wrote: >> Time is actually harder than it seems. Many bits of software break in >> unexpected ways. Expect the unexpected. > > Aye. How many have written code like this: >

Re: Leap Second planned for 2016

2016-07-08 Thread Harlan Stenn
On 7/8/16 4:47 PM, Saku Ytti wrote: > On 9 July 2016 at 02:27, Jared Mauch wrote: >> Time is actually harder than it seems. Many bits of software break in >> unexpected ways. Expect the unexpected. > > Aye. How many have written code like this: > > start = time(); >

Re: Leap Second planned for 2016

2016-07-08 Thread Eric Tykwinski
That was great, I would actually like NIST to link to it… > On Jul 8, 2016, at 7:14 PM, Hal Ponton wrote: > > I'll just leave this here :) > > http://spendyourleapsecondhere.com/ > -- > -- > Regards, > > Hal Ponton > Senior Network

Re: Leap Second planned for 2016

2016-07-08 Thread Saku Ytti
On 9 July 2016 at 02:27, Jared Mauch wrote: > Time is actually harder than it seems. Many bits of software break in > unexpected ways. Expect the unexpected. Aye. How many have written code like this: start = time(); do_something(); elapsed = time() - start; Virtually

Re: Leap Second planned for 2016

2016-07-08 Thread Jared Mauch
Time is actually harder than it seems. Many bits of software break in unexpected ways. Expect the unexpected. Jared Mauch On Jul 8, 2016, at 6:53 PM, Javier J wrote: >> Time to start preparing > > > Unless you are running something that can't handle leap seconds

Re: Leap Second planned for 2016

2016-07-08 Thread Hal Ponton
I'll just leave this here :) http://spendyourleapsecondhere.com/ -- -- Regards, Hal Ponton Senior Network Engineer Buzcom / FibreWiFi Andrew Kirch 9 July 2016 at 00:09 Its a whole extra second you can spend doing something awesome. You have to plan now!

Re: Leap Second planned for 2016

2016-07-08 Thread Andrew Kirch
Its a whole extra second you can spend doing something awesome. You have to plan now! On Friday, July 8, 2016, Javier J wrote: > > Time to start preparing > > > Unless you are running something that can't handle leap seconds what do you > really need to prepare for?

Re: Leap Second planned for 2016

2016-07-08 Thread Javier J
> Time to start preparing Unless you are running something that can't handle leap seconds what do you really need to prepare for? On Thu, Jul 7, 2016 at 12:59 PM, Andrew Gallo wrote: > Looks like we'll have another second in 2016: >