Its a whole extra second you can spend doing something awesome. You have to plan now! On Friday, July 8, 2016, Javier J <javier@advancedmachines.us> wrote:

...

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 <akg1330@gmail.com <javascript:;>> wrote:

...

Looks like we'll have another second in 2016: http://www.space.com/33361-leap-second-2016-atomic-clocks.html

Time to start preparing

That was great, I would actually like NIST to link to it…

On Jul 8, 2016, at 7:14 PM, Hal Ponton <hal@buzcom.net> wrote:

I'll just leave this here :)

http://spendyourleapsecondhere.com/ <http://spendyourleapsecondhere.com/> -- -- Regards,

Hal Ponton Senior Network Engineer

Buzcom / FibreWiFi

...

Andrew Kirch <mailto:trelane@trelane.net <mailto:trelane@trelane.net>> 9 July 2016 at 00:09 Its a whole extra second you can spend doing something awesome. You have to plan now!

Javier J <mailto:javier@advancedmachines.us <mailto:javier@advancedmachines.us>> 8 July 2016 at 23:53

...

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<akg1330@gmail.com> wrote:

...

Looks like we'll have another second in 2016: http://www.space.com/33361-leap-second-2016-atomic-clocks.html

Time to start preparing

Andrew Gallo <mailto:akg1330@gmail.com <mailto:akg1330@gmail.com>> 7 July 2016 at 17:59 Looks like we'll have another second in 2016: http://www.space.com/33361-leap-second-2016-atomic-clocks.html <http://www.space.com/33361-leap-second-2016-atomic-clocks.html>

Time to start preparing

On 9 July 2016 at 02:27, Jared Mauch <jared@puck.nether.net> 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 all code dealing with passage of time assumes time moves only forward, I'm amazed we don't see more issues during leap seconds. Portable monotonic time isn't even available in many languages standard libraries. Hopefully they'll decide in 2023 finally to get rid of leap seconds from UTC. Then GPS_TIME, TAI and UTC are all same with different static offset. -- ++ytti

On Jul 8, 2016, at 7:47 PM, Saku Ytti <saku@ytti.fi> wrote:

On 9 July 2016 at 02:27, Jared Mauch <jared@puck.nether.net> 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 all code dealing with passage of time assumes time moves only forward, I'm amazed we don't see more issues during leap seconds. Portable monotonic time isn't even available in many languages standard libraries.

Hopefully they'll decide in 2023 finally to get rid of leap seconds from UTC. Then GPS_TIME, TAI and UTC are all same with different static offset.

But time _DOES_ flow. The seconds count 58, 59, 60, 00, 01, … If you can’t keep up, that’s not UTC’s fault. As for stopping the leap seconds, talk to the planet Earth. It’s the one who will not conveniently rotate properly. Either that, or run REEEEEEALLY Fast in that -> direction every once in a while. :-) -- TTFN, patrick

Chris Adams <cma@cmadams.net>:

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 would have drifted slightly, but so what?

Here is "so what". From my blog, earlier this year: "In defense of calendrical irregularity" I’ve been getting deeper into timekeeping and calendar-related software the last few years. Besides my work on GPSD, I’m now the tech lead of NTPsec. Accordingly, I have learned a great deal about time mensuration and the many odd problems that beset calendricists. I could tell you more about the flakiness of timezones, leap seconds, and the error budget of UTC than you probably want to know. Paradoxically, I find that studying the glitches in the system (some of which are quite maddening from a software engineer’s point of view) has left me more opposed to efforts to simplify them out of existence. I am against, as a major example, the efforts to abolish leap seconds. My reason is that studying this mess has made me more aware than I used to be of the actual function of civil timekeeping. It is to allow humans to have consistent and useful intuitions about how clock time relates to the solar day, and in particular to how human circadian rhythms are entrained by the solar day. Secondarily to maintain knowledge of how human biological rhythms connect to the seasonal round (a weaker effect but not a trivial one). Yes, in theory we could abolish calendars and timestamp everything by atomic-clock kiloseconds since an epoch. And if there ever comes a day when we all live in completely controlled environments like space habs or dome colonies that might actually work for us. Until then, the trouble with that sort of computer-optimized timestamp is that while it tells us what time it is, it doesn’t tell us what *kind* of time it is – how the time relates to human living. Day? Night? Season? Those sideband meanings are an important component of how humans use and interpret time references. Yes, I know January in Australia doesn’t mean the same thing as January in the U.S. – the point is that people in both places have stable intuitions about what the weather will be like then, what sorts of holidays will be celebrated, what kind of mood is prevalent. I judge that all the crap I go though reconciling scientific absolute time to human-centered solar time is worth it. Because when all is said and done, clocks and calendars are human instruments to serve human needs. We should be glad when they add texture and meaning to human life, and beware lest in our attempts to make software easier to write we inadvertently bulldoze away entire structures of delicate meaning. UPDATE: There is one context, however, in which I would cheerfully junk timezones. I think timestamps on things like file modifications and version-control commits should always be kept, and represented, in UTC, and I’m a big fan of RFC3339 format as the way to do that. The reason I say this is that these times almost never have a human-body-clock meaning, while on the other hand it is often useful to be able to compare them unambiguously across timezones. Their usage pattern is more like scientific than civil time. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

On 9 July 2016 at 22:09, <A.L.M.Buxey@lboro.ac.uk> 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 pathological if the elapsed time is long, it may not break anything if they are 1s off. And if they measure short elapsed time, but are done infrequently, you might just not have hit the code path at the right moment. I'm sure you've had your share of difficult to track down bugs requiring very specific set complicated conditions. I give little value in black-box testing, lot of effort and very high chance of just not hitting all bug prerequisites, unit testing is much more fruitful, but alas in walled garden not possible. ++ytti

On 9 July 2016 at 04:39, Patrick W. Gilmore <patrick@ianai.net> 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 broken. You have to use monotonic time to measure passage of time, which is not particularly easy to do portable, in some languages.

As for stopping the leap seconds, talk to the planet Earth. It’s the one who will not conveniently rotate properly. Either that, or run REEEEEEALLY Fast in that -> direction every once in a while. :-)

In practice this does not appear to be significant problem. Several thousand years must pass until clocks have shifted one hour, and we have experience on shifting clocks one hour within a year, so I'm sure we can tolerate slippage caused by not having leaps. I'm holding my thumbs up for 2023 and sanity prevailing. -- ++ytti

POSIX (Unix) (normal) time does not have leap seconds. Every POSIX (Unix) (normal) minute has exactly 60 seconds. Every POSIX (Unix) (normal) hour has exactly 60 minutes. Every POSIX (Unix) (normal) day has exactly 24 hours. Every POSIX (Unix) (normal) year has 365 days, unless it is a leap year, in which case it has exactly 366 days. The POSIX time is the number of seconds (or parts thereof) that has passed since midnight, 1 January 1970 GMT. The time scale is UT1. Outside of very specialized scientific applications, EVERY computer system everywhere uses POSIX time and does time/date calculations based on POSIX time (UT1). UTC time has leap seconds. This is because UTC is a "different" time-scale than the UT1 timescale on which POSIX/Unix time is based. UTC proceeds at a different "rate" from UT1 and so, from time to time, UTC time must be adjusted to keep it in sync with POSIX/Unix (normal) time.

-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Valdis.Kletnieks@vt.edu Sent: Saturday, 9 July, 2016 15:12 To: Saku Ytti Cc: NANOG list Subject: Re: Leap Second planned for 2016

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

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 of international acronym agencies to come up with something better by 2023. The problem remains that simply abandoning leap seconds has the effect of redefining the calendar, and Pope Gregory's last attempt to do that took 300 years to consolidate. For time scales there are three desirable goals, but it is only possible to pick two http://www.ucolick.org/~sla/leapsecs/picktwo.html -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

On Sun, Jul 10, 2016 at 3:27 AM, Saku Ytti <saku@ytti.fi> 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 purposes of Timestamping or synchronizing events down to a Per-Second or Subsecond resolution. Suggest revising Unix/POSIX Time implementation to use a 3-Tuple representation of calendar time, instead of a single Integer. typedef int64_t time_t [3]; [ Delta from Epoch in Seconds, Delta in Microseconds, Cumulative Leap Adjustment from the Epoch in Microseconds] Thus to compare two timestamps A and B long long difference_in_seconds(time_t A, time_t B) { return (B[0] - A[0]) + ( B[1] - A[1] + B[2] - A[2] ) /1000000; } -- -JH