Extra Leap Second To Be Added To Clocks On June 30

hcs_$reboot writes: On June 30 this year, the day will last a tad longer — one second longer, to be precise — as a leap second is to be added to clocks worldwide. The time UTC will go from 23:59:59 to 23:59:60 in order to cope with Earth's rotation slowing down a bit. So, what do you intend to do during that extra second added to that day? Well, you may want to fix your systems. The last time a leap second was added, in 2012, a number of websites, Java and even Linux experienced some troubles. Leap seconds can be disruptive to precision systems used for navigation and communication. Is there a better way of dealing with the need for leap seconds?

Comments

Leap hour

[yet another SanTiago]

There is a better way. Just wait several thousand years and then add one leap hour.

Re:Leap hour

[yet another SanTiago]

Well, i hope DST would be abandoned sooner.

Re: Leap hour

[jaa101]

There's already "Ephemeris Time" (ET) that doesn't have leap seconds. It's now exactly 26 seconds different from UTC. Go ahead and use that for system time if you like.

Better way

[itzly]

Of course, there's a better way. Just ignore the small error until it adds up to an hour, and then skip a DST transition.

Re:Better way

[gstoddart]

And then over time the astronomical meaning of how we keep time goes astray.

AM and PM mean "anti-meridian" and "post-meridian", and at noon on the day of the summer solstice, the sun should sit on the celestial meridian.

I'm pretty sure if we did it your way, eventually the meridian (which is how we derived both navigation and time keeping) would move around, and eventually noon would be in the middle of the night.

This stuff isn't arbitrary, it's actually based in something.

The whole point of the leap second (etc) is to keep those things lined up. Otherwise there is no way we could keep track of things like sunrise and sunset, or when you might see a specific star.

Re:Better way

[CrimsonAvenger]

Wait a century or so, do a Leap Minute. We won't be bothered by the silly thing if they only happen once in a lifetime, if that often.

Re:Better way

[riverat1]

UTC doesn't do daylight savings time.

Re:Better way

[jones_supa]

DST is a clear one hour offset. We know precisely what the time without the DST addition is at any given moment. Letting the time slide second-by-second until we reach the extra hour would be quite a different thing.

Re:Better way

[smooth wombat]

AM and PM mean "anti-meridian" and "post-meridian", and at noon on the day of the summer solstice, the sun should sit on the celestial meridian.

I'm glad you phrased it that way. Countless times I have seen people, signs and web sites refer to times such as 12 PM or 12 AM.

There are no such times. It's either 12 noon or 12 midnight.

Re:Better way

[r_jensen11]

And then over time the astronomical meaning of how we keep time goes astray.

By that logic, the astronomical meaning of how we keep time went astray when we implemented time zones.

Re:Better way

[TWX]

Explain the, how DST works in relation to "noon" and "midnight". AM and PM are more like guidelines than actual code.

I think your use of DST was wrong, I think you meant timezones.

Timezones break local noon/midnight by offsetting the location to an approximate less than a half-hour away, but since timezones are calcuated based on the arbitrarily-picked Greenwich, UK, really the entire planet is running on Greenwich time, with a particular significant digit adjusted to reflect distance, to approximate the natural time of the area.

Re:Better way

[TheCarp]

> AM and PM mean "anti-meridian" and "post-meridian",

Total nitpick, its ante not anti.

ante- prefix meaning before
anti - prefix meaning against

You see it in words like "antediluvian" (before the flood).

Re:Better way

[Anonymous Coward]

And countless times I see people assume that traditional latin and/or greek roots of terms must be taken literally and dictate how they are to be used in modern times...

Numerous national standards define midnight as 12:00 AM or 0:00 AM, and noon as 12:00 PM. But many also recommend the written usage of "12 noon" and "12 midnight" to make things clear to those that don't understand AM and PM.

Re:Better way

[xaxa]

arbitrarily-picked Greenwich, UK,

Greenwich wasn't arbitrarily picked. The only options were Paris, Berlin, London and Washington DC -- they had the necessary observatories. London was already in widest common use, and the anti-meridian falls in a convenient place (not crossing anywhere important).

Re:Better way

[msauve]

Standard Time still had local time coupled with sol, to an approximation of about 1/2 hour (stretched for political boundaries and other practical reasons, etc.) One could measure the offset between Standard Time and their local solar time, and use that to determine Standard Time independently at any point in the future.

UTC is likewise closely coupled with solar time (UT1) within 0.9 seconds. If you know the offset of a location, you can determine UTC at that location within 0.9 seconds independently, using only astronomical means.

Decoupling UTC from sol breaks the millenia old convention that civil time is based on sol, for the sake of some lazy programmers.

Better way?

[msauve]

"Is there a better way of dealing with the need for leap seconds?"

Sure, use/write software which correctly handles time. Leap seconds with their current, well defined behavior, have been around for over 40 years.

If you have software which assumes a minute is always 60 seconds, an hour is always 60, 60 second minutes, etc., you're doing it wrong.

Re:Better way?

[msauve]

What you're suggesting is a variable length second. That's what GMT was before the current UTC came along. The slowdown of Earth's rotation is NOT a known factor, it varies. Things like earthquakes can change the period unpredictably.

Modern UTC ticks at a predictable rate, which is useful for some sciences. Leap seconds keep it in sync with the Earth's rotation, which is useful for others. UTC with leap seconds was deliberately intended to bridge those two needs.

If someone wants a time scale without leap seconds they shouldn't be using UTC, there are others to choose from, such as TAI or GPS.

Re:Better way?

[CastrTroy]

You still end up with problems like when is 1:30 AM when you switch off DST. Is it the 1:30 AM before or after the clocks changed? 1:45 AM EDT is actually before 1:30 AM EST. Also, systems probably have to deal with this kind of junk all the time. Very few computers have an extremely accurate clock, so they have to be adjusted every so often anyway. If your system can't handle the time getting set back by a second or two, then you are going to run into problems whenever you recalibrate your clock. At least if you don't have unexpected things like 23:59:60 happening, then it will work for the majority of situations. Systems the really need to care about the leap second can account for it, and to the rest of the systems that really don't care about it, it will just look like a clock recalibration.

Re:Better way?

[DarkOx]

DST isn't so much a problem because if you are doing things right, mostly you store time in UTC and apply the timezone when you display it or convert human inputs from it. Well really some library does this for you using the published tzdata but you get the idea. This gives monotone time, in that its always increasing. Your proposal actually makes things harder because you will end up with two events that logically can't coincide having potentially the same timestamps or even timestamps that appear in the wrong order depending on resolution.

Suppose Job A is suppose to run at 23:59:59.00
Job B uses the output of Job A and is an event triggered completion of job B

Job A logs that it started at 23:59:59.01
Job A logs it completed at 23:59:59.97 (it took less than a second to run)
Now we insert our leap second by resting the clock to 23:59:59.00 again
Job B runs and logs its start time at 23:59:59.02 (this should be impossible! A isn't finished yet)

And really most of the time logs of least concern, but you would create problems for all kinds of systems that interact with each other and make time based decisions.

Re:Better way?

[0123456]

Life's too short. I'll let NTP deal with it and happily ignore leap seconds.

That's what most people thought before the last leap second, then they found all their Java services sucking up 100% of the CPU in the morning.

Re:Better way?

[Darinbob]

Or just don't worry about it. I work with systems where you must deal with clock drift over time and time drift across the network. So the addition of a second doesn't change much at all. The times when it matters most is with things like satellite navigation systems.

Re:Better way?

[jdschulteis]

How about instead of setting the time to 23:59:60, the value 23:59:59 happens twice. When we have DST, and the time falls back an hour, we don't switch to some odd non-existant number for an hour so that we don't have overlap. We just set the clocks back to 1 AM. So all the times between 1 AM and 2 AM happen twice when switching off daylight savings.

The times between 1 AM and 2 AM don't really happen twice on the day daylight time ends, they are simply ambiguous unless daylight or standard time is specified. (In other words, you don't know which of 2 possible seconds 1:42:42 AM refers to until daylight or standard time is specified.) Similarly, your proposal would make 23:59:59 ambiguous without some additional specifier, in which case why not just use 23:59:60?

There is no one perfect solution, which is why there are multiple time standards, including TAI and GPS which do not incorporate leap seconds.

Many programmers are ignorant as to the more subtle aspects of timekeeping.

It does not help that for many programs, it simply doesn't matter.

It is also very easy to slip assumptions that are broken by leap seconds into code. (Every minute has 60 seconds--wrong! Every hour has 3600 seconds--bzzt! Every day has 86400 seconds--fail!)

Re:Better way?

[nedlohs]

23:59:60 != 00:00:00 is the point.
It's an extra second inserted between 23:59:59 and 00:00:00. During that extra second the clock reads 23:59:60.

Re:Better way?

[ihtoit]

because 23:59:60 isn't 00:00:00. It's 00:00:00-1. Ergo, it should read 23:59:60 otherwise you'll catch the clock in an endless loop as it repeatedly applies the adjustment to 23:59:59 so it reads 23:59:59 again, to have it happen just once you just make the last minute of that one particular day last 61 seconds (remember this is an adjustment to STORED TIME, not DISPLAYED TIME).

Man vs Machine?

[duckintheface]

There are two domains to consider.... human and computer. Humans won't notice or care about sunrise being off by one second or even much more than that. Computers need exact consistency. So the solution is, as stated, to update the clocks to the actual rotation only infrequently. Everyone, man and machine, will be happy.

Re:Man vs Machine?

[Shakrai]

That POS real-time clock mechanism in your average PC holds time as good as a $10 wristwatch

NTP can keep time to within tens to hundreds of milliseconds across the public internet. Plenty good enough for 99.9999% of the applications out there. The RTC only comes into play across reboots. Even Windows has implemented NTP (albeit a crappy implementation that's "only" good to within a second or two) by default for more than a decade now.

Re:Man vs Machine?

[bickerdyke]

Ignoring the "more stuff would break", this wouldn't help either, as not every day is that 0.000..001% longer. Rotation of the earth is much more irregular than precision timekeeping stuff.

Re:Man vs Machine?

[Obfuscant]

Even Windows has implemented NTP (albeit a crappy implementation that's "only" good to within a second or two) by default for more than a decade now.

The default for Windows 7 (non-domain) is to update once a week, and I routinely found my PVR system off by a minute or more. There is a way to change the update interval but you either need to download a special program to make the changes or edit the registry by hand.

Re:Man vs Machine?

[david_thornley]

How accurate is a sextant? If it doesn't accurately provide seconds of arc, a one-second discrepancy won't matter.

here is the draft set of possible options

[at10u8]

A recent draft of the set of options which will be presented when the World Radio Conference votes this fall is visible at http://acma.gov.au/Industry/Sp... This draft has options A, B, and C, but it is likely to be wordsmithed a lot before it is finished.

Re:here is the draft set of possible options

[Anonymous Coward]

I hope they don't chose option A. It's a hack. We already have a timescale that doesn't add leap seconds: TAI. Changing the definition of UTC is just a hack to fix broken systems. But there are so many other problems with the way systems handle time that it's kind of a moot point.

Properly written software that requires continuance SI-seconds units will use TAI or if they don't need a global reference a local monotonic clock.

Even TAI is something of a lie. Relativity tells us that time is relative, so any global reference clock on earth necessarily has limited precision.

My favorite time scale is POSIX. They define a day as precisely 86400 "seconds". Obviously a POSIX second is not the same as an SI second. But it makes it trivial to compute past and future dates using a 4-line algorithm. And for _civilian_ usages, it's all you'll ever need. If you need high precision or scientific accuracy, you shouldn't be using UTC anyhow.

The root of the problem is that people don't think about what kind of clock reference they really need. And when they convert, they don't think about the lossiness of conversion between different time scales and units. (Like with floating point arithmetic there are rules you can follow.) Hacking UTC won't make the idiots any smarter, and it's a fool's errand to think that the whole world wants or needs a single global time reference.

Civilian time should be synchronized to the sidereal day. Business records don't need sub-second precision; 99% of the time we think in larger units like minutes, hours, and days. And all they matters is the transition between one minute, one hour, or one day to the next, regardless of the duration of an SI-second. Leap seconds and leap years are a decent compromise.

People need to _think_ about the function of time in their applications, and stop pretending like it's a simple problem or that it can solved for you by tweaking international standards. Alternatively, just adopt the POSIX definition of the second and the day and be done with it. A POSIX day is 86400 "seconds", and by implication a POSIX "second" is not the same as an SI second and doesn't (cannot!) have a fixed duration. But that will work for the vast majority of civilian business applications. POSIX also defines a monotonic clock, which should be the local reference for an SI-second. And for the very few applications (mostly scientific) that rely on a global reference clock, just use TAI.

Problem solved. And I didn't even need to redefine the concept of time to something completely alien to normal humans.

Re:Earth not _turning_ slower, but already is slow

[Russ1642]

The problem is that you don't understand it.

Re:Is there a better way?

[Archangel Michael]

You know in advance already, they are giving you about six months advance notice. Make sure your code handles generic "leap event" with the ability to input the actual values at future, undetermined time ... but in advance of the actual leap event. I could see it requiring at least two inputs, Value change, and time to insert said time.

Should be easy.

This is what's wrong with "renewable" energy

[ScentCone]

First, you've got all those new solar panels absorbing photons from the sun, but only in one direction, and then you've got all of those wind farms and tidal hydro plants adding friction to things. Of course the earth is being slowed down. Every time some do-gooder plants a tree, what do you think happens? More friction. Friction slows down the planet and causes heat. Check it for yourself - try walking briskly to the fridge and back, and then try shuffling your feet on the carpet as you do the same. Heat! Slowing down! Exactly like what happens when the atmosphere has to slide over something that's in the way, like a rainforest. No matter how many coal-bearing mountains we smooth out to help with this problem, the infestation of "tiny houses" clustered around hipster-friendly towns just slows the air back down again.

Re:Do the impossible

[bigwheel]

All we need to do is have everyone in the world face west and run.

Re:Earth not _turning_ slower, but already is slow

[gclef]

No, the Earth really is slowing down very, very gradually. The tidal forces from the moon is slowly leeching off rotational energy from the Earch (as heat). See here: http://en.wikipedia.org/wiki/T...

Re:Earth not _turning_ slower, but already is slow

[gclef]

Note to self: get more sleep before commenting....it's losing rotational energy to pushing the moon farther away. Gah.

Re:Is there a better way?

[msauve]

If it's not network connected (ntp or gps), or connected to a properly calibrated atomic clock, it's going to be off by more than a second when the next leap second rolls around, anyway.

If you don't need time accurately sync'd to UTC, you can ignore leap seconds, so what's the problem? And if you do need time sync'd to UTC, you will need some regular external input which can include upcoming leap second info, so what's the problem?

"Is there...

[Minwee]

...a better way of dealing with the need for leap seconds?"

Well... It could be worse. The last time we let the clocks go off we lost almost two weeks trying to fix it.

Let's just keep up with the leap seconds so that nobody has to cancel Christmas again.

Fix NTP

[amorsen]

The main problem is the wrong handling of UTC by NTP and Unix.

NTP is simply on the wrong time system. It is a system which is designed to accurately keep a monotonous steady time shared among millions of systems spread across time zones. It does not have any sensible way of dealing with the fact that some systems want to suddenly add a second or subtract one, just like it cannot deal with time zones or Mayan calendars. Those are simply outside its problem domain. Luckily the fix is simple: Stop handling leap seconds at all in NTP, just keep counting seconds. If you must handle it in NTP for those client systems too primitive to do it themselves, do it by transmitting the current offset between NTP time and UTC. The best solution would be to define NTP time to be TAI of course, but it will likely have to be TAI+offset to handle backwards compatibility.

Unix again does it wrong by keeping system time in UTC rather than TAI. UTC is useful for humans but difficult for machines, it should be handled by the human interface libraries, just like time zones. Kernel time should be TAI of course. When leap seconds are inserted, systems must be updated, but that is not particularly harder than keeping the time zone files up-to-date is already. Of course it would be a lot easier if the astronomers would let us know a few years in advance rather than six months, but then the offset between TAI and UTC could exceed 0.9 seconds, and as we all know that would bring Ragnarok.

GNU systems even have sets of time zones for precisely this reason: "POSIX" and "Right". Unfortunately it is not possible to use the "Right" time zones with current NTP.

Re:Fix NTP

[Guy Harris]

Unix again does it wrong by keeping system time in UTC rather than TAI.

Actually, that's not what POSIX does, for any definition of "keeping system time in UTC" corresponding to the ITU-R specification, as the POSIX definition of "seconds since the Epoch" and its mapping to a struct tm doesn't allow the seconds value to be 60, which it will be during a positive leap second.

I.e., it's even more wrong - a POSIX-compliant time_t isn't something that corresponds to TAI (as it doesn't tick forward by 1 every second of elapsed time) and you can't generate valid UTC labels (YYYY-MM-DD HH:MM:SS) from it.

UTC is useful for humans

...but I suspect few clocks used by humans give a local time corresponding to UTC - most of the digital ones won't show "60" in the seconds section one second after June 30, 2015 at 23:59:59 UTC, and I don't know what the right thing to do for the second hand on an analog clock would be (for an analog clock without a second hand, presumably the minute hand should move two seconds after June 30, 2015 23:59:59 UTC).

but difficult for machines, it should be handled by the human interface libraries, just like time zones. Kernel time should be TAI of course.

I.e., "seconds since the Epoch" should actually be a count of the number of seconds that have elapsed since the Epoch, rather than being, well, what it is.

When leap seconds are inserted, systems must be updated,

...and whatever data structures are used to keep tract of future scheduled events might have to be updated to reflect that, for example, July 1, 2015, 00:00:00 UTC is going to be one more second later than was expected at the time an event was scheduled for that date and time.

However, having system time tick ahead one second every second means that events scheduled to occur N seconds from now, rather than scheduled to occur at YYYY-MM-DD HH:MM:SS UTC, won't have their time messed up by leap seconds; it's not as if the POSIX solution doesn't screw up anything.

but that is not particularly harder than keeping the time zone files up-to-date is already.

Especially given that leap seconds are part of the Olson^WIANA time zone source files.

Re:Fix NTP

[Guy Harris]

Yes you are right, I had forgotten just how broken POSIX time is. Completely unfixable.

Which is stupid, because struct tm actually supports leap seconds and even (despite them not being possible) double leap seconds.

Thank Doug Gwyn for that one - he pushed that in ANSI C so that it could handle leap seconds.

(And I pushed for leap-second-capable time in POSIX, but they didn't go for it.)

...and whatever data structures are used to keep tract of future scheduled events might have to be updated to reflect that, for example, July 1, 2015, 00:00:00 UTC is going to be one more second later than was expected at the time an event was scheduled for that date and time.

This bit you already have to handle due to daylight savings and time zone changes. If the user inputs a local date and time for a particular event, it is NOT valid to convert and store that as seconds after the epoch. That conversion can change anytime.

Yup, there's no guarantee that, if you calculate the number of seconds between "right now" and YYYY-MM-DD HH:MM:SS, whether that's local time or UTC, that will be the number of seconds in the future when YYYY-MM-DD HH:MM:SS will actually happen.

I wonder how many calendar programs cope with that.

TAI if you need it (was Re:Is there a better way?)

[Etcetera]

If you're doing calculations on time using intervals, and one second matters to you, you should be using a raw number instead of calculating the "23:59:59" yourself. If the UTC conversion is too much, use TAI instead and be done with it:

From http://en.wikipedia.org/wiki/International_Atomic_Time:

International Atomic Time (TAI, from the French name Temps atomique international[1]) is a high-precision atomic coordinate time standard based on the notional passage of proper time on Earth's geoid.[2] It is the basis for Coordinated Universal Time (UTC), which is used for civil timekeeping all over the Earth's surface, and for Terrestrial Time, which is used for astronomical calculations.

Re:Ok, so I'm temporally challenged ...

[Russ1642]

23:59:59 is normally followed by 00:00:00 (or 24:00:00). In this case it goes 23:59:59, 23:59:60, and then 00:00:00. One second gets added at the end of the day.

Headline is repetitive and tautological

[wonkey_monkey]

Extra Leap Second To Be Added To Clocks On June 30

It's not an extra leap second, it's just a leap second. They're already "extra" by definition.

Yours sincerely,

Captain Pedantic

Re:Earth not _turning_ slower, but already is slow

[TFlan91]

This post right here is why we need a "Post Inaccurate" option for modding.

Re:Earth not _turning_ slower, but already is slow

[floateyedumpi]

Most of the depleting rotational energy of the Earth goes into the orbital energy of the moon, which means the moon will be boosted in its orbit and recede from Earth until the Earth is slowed down enough that the same side of the Earth faces the moon as it orbits ("tidally locked"). Which, by the way, is why the man in the moon always faces us (i.e. tidal locking happened long ago on the moon). At that point, a day and Earth an an orbit on the Moon would both last about 47 days. Estimates for when this would occur are around 50 billion years, by which time the sun will have swollen up in its death throes and consumed the Earth. There is some heat generated due to friction from tides and distortions of the Earth's crust, but the rotational-orbital exchange is much more significant.

Bloody EU, always meddling.

[Hognoxious]

England told him to bugger off.  Hence, on a unix system:

$ cal 9 1752
   September 1752
Su Mo Tu We Th Fr Sa
       1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30