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

[NotInHere]

or several million years, and add a second every day!

Re:Leap hour

[rossdee]

Just wait thousands of years and then not put the clocks forward in march

Re:Leap hour

[yet another SanTiago]

Well, i hope DST would be abandoned sooner.

Re:Leap hour

[Macdude]

An even better way, wait several thousand years and the sun will come up at 7 am instead of 6 am.

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.

Re:Leap hour

[antdude]

Not until we are back on DST and then we can dump it. :P

Re:Leap hour

[davester666]

No. Large rocket engines mounted horizontally, fixed to the Earth, running 24/7 until we get the rotation back up so we don't have to keep adding these stupid seconds.

Re:Leap hour

[grantspassalan]

According to this link referenced in the article,

http://www.telegraph.co.uk/new...

“From 1972 to 1979, at least one second was added every year. Leap seconds were added six times throughout the 1980s. But there will only have been four leap seconds added since 1999.”

This means that something very fishy is going on because this can add up to a very large error over time. In only seven years from 1972 to 1979 seven seconds were added! This means that at this rate of change, 13,797 seconds would have to be added to the day at the beginning of year 1. That comes to 3.83 hours in time of Christ! I cannot envision that the Roman’s day was almost 4 hours longer than ours! I suspect that the Earth’s rotation does not change by anywhere near that much if at all. Atomic clocks are extremely accurate short-term, but it seems from this data that their long term accuracy leaves a lot to be desired.

Re:Leap hour

[grantspassalan]

From 1972 to 1979 they added one second to every year. At that rate, and 1 million years that would amount to 1 million seconds. That is total silliness. It would mean that 1 million years ago it took 11 ½ of our days for the earth to turn on its axis once! It seems that the atomic clock is totally an accurate long-term.

Re:Leap hour

[mwvdlee]

Leap time is due to the time it takes for the earth to rotate around the sun, not the time it takes for the earth to spin around it's own axis.

The earth doesn't rotate around the sun at a completely predictable speed (=something fishy), which is why leap seconds cannot be announced a great deal ahead of time (or extrapolated into the past).

Also, if you WERE to extrapolate at one second every year, that's about 2,000 seconds to year 1, not 13,797. Besides, I have no problem envisioning days that might be a few hours longer or shorter than ours. The average human would not even notice it.

It should also be noted that they started adding leap seconds in 1972. The fact that from 1972 to 1979 there were so many was mainly because they were trying to catch up without introducing too many leap seconds at once. In fact they even added two leap seconds in first year!

Wikipedia (http://en.wikipedia.org/wiki/Leap_second#Slowing_rotation_of_the_Earth) explains this better than I did.

Atomic clocks are extremely acurate long term, they just don't measure the "wobbly" time it takes for the earth to rotate around the sun.

Re:Leap hour

[Neil Boekend]

bad idea

Re: Leap hour

[tricorn]

Exactly. The system clock should be uniform and continuous down to the resolution of the system/hardware. All conversions to/from wall time (including time zones, DST, and leap seconds) should be done separately. The tz database/library is already capable of supporting that mode.

I think it was one of the biggest mistakes in time processing to have NTP adjust the system clock on a leap second. Have NTP include the current offset, even have something that automatically updates the leap second history file when NTP indicates a pending leap second (or is showing a different offset from the current database, which would indicate that a database update is needed, say for a system that's been turned off or disconnected for a long time - not perfect, but close).

This could be phased in in several ways, perhaps just changing it and overriding the few programs that would break (perhaps with a per-process flag to modify the kernel calls to get the time, which the tz library could take into account).

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

[Archangel Michael]

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

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

[itzly]

You must have missed the part where I said to correct the error when it has grown to an hour.

at noon on the day of the summer solstice, the sun should sit on the celestial meridian.

Many people around the world live in a time zone that's already an hour off. What's a few more seconds/minutes ? All of China has a single time zone, and they still manage to survive.

Otherwise there is no way we could keep track of things like sunrise and sunset, or when you might see a specific star

You don't think we could simply adjust the calculations for sunrise and sunset ?

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

[BarbaraHudson]

It's no big deal to add a leap second every once in a while. Most of our devices that have a time component synchronize time from a centralized source (the cell network, the internet) so you won't even notice. For the other stuff, like my microwave and coffee maker and stove, if it goes out of sync by a second every few years I won't notice because power failures are more often than that, and time only goes to hh:mm anyway.

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

[Wesley Felter]

Like how people weren't bothered by Y2K bugs? Let's not repeat that every century.

Re:Better way

[PseudoCoder]

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.

That will lead to more and bigger instances of being affected by the error. The error is always there to a degree, no? But you are only affected by the error when you read the clock and produce a "bad calculation" based on that reading.

Not sure what the answer would be software-wise, but maybe more use of elapsed time routines (vs absolute time) that would account for the corrected clock.

Re:Better way

[Roger W Moore]

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.

This is only ever true if you happen to live precisely on the meridian for your time zone. Given that almost nobody does and that timezones often are determined more by politics than science most people on the planet are already living out of sync with the strict astronomical definition of time by many tens of minutes if not hours.

If we can handle timezones which are an hour wide then we can handle being an hour off between astronomical time and legal time and so if should be fine to buffer the changes until they make up an hour which will take ~7,200 years if the rate is one second every ~2 years (a period longer than any human calendar has ever remained in use for).

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

[angel'o'sphere]

No, it does not.
You seem not to understand time and time zones ;) no problem, it takes time to do that.

Re:Better way

[nedlohs]

Sane people don't care about such ridiculous restrictions.

If it makes you feel better you can just read 12 PM and 12:00:00.0000000001 PM if you like - which should also show the idiocy of the restriction in the first place.

Re:Better way

[Livius]

An hour is 1/24 of a day, so maybe that's a little too much, but I doubt any human activity would be affected if we saved up the discrepancies until it was a half or a full minute.

Re:Better way

[Gavagai80]

We will. I've noticed a lot of people are already back to entering years in two digits.

Re:Better way

[Livius]

Noon versus midnight is nowhere near as troublesome as ensuring you're clear on which day midnight belongs to. A lot of things get scheduled for 12:01 am or 11:59:59 pm for that reason.

Re:Better way

[Gavagai80]

Your astronomical noon is not at actual noon, nor is midnight the middle of your night. In fact, the time of astronomical noon changes by a few minutes as you drive even short distances east or west. It would take centuries of of leap seconds to diverge from astronomical noon as much as driving to the next city does.

Re:Better way

[david_thornley]

Hey, I was paid in part to deal with Y2K bugs. Let's not complain.

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

[Archangel Michael]

No, I meant DST, which causes fluctuations in time by one hour twice a year based on political whim and originally proposed as a joke/insult to France by Benjamin Franklin.

Which incidentally proves two things: You should never joke with politicians, they may think it is a good idea and implement it. And politicians are stupid.

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.

Re:Better way

[angel'o'sphere]

You are mixing up local noon ... with everything else.

Who cares about driving? Point is, if your clock is wrong you add to the minutes you are concerned about another second. And a minute only has 60 seconds. So you are off by another second if you don't factor in leap seconds.

Re:Better way

[GNious]

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.

Easier to remember as After Midnight and Pefore Midnight :)

Re:Better way

[Zappy]

"anti-meridian"

ante-meridian, anti-meridian would be midnight I guess :-)

Re:Better way

[Neil Boekend]

DST aligns it better. Noon shifts through the year because the Earth orbit is not completely round.
What we see as a day is the sum of two effects:
1. The rotation of the earth around it's axis. This takes about 23 hours and 56 minutes. Understand it as "relative to the stars in the background". It is called sidereal time.
2. Our orbit around the sun. This adds 4 minutes to each day. If the earth would not rotate relative to the stars in the background this would still cause one "day" per year.
Total is approximately 24 hours.

The rotation around our axis is relatively constant. Sufficiently constant for this.
The orbital speed is not constant. The orbit is not round, there is a point where the planet is closer to the sun. The closer the earth is to the sun the faster it goes.
The faster the earth goes the more degrees per hour the sun movement by the day-caused-by-our-orbit is.
This causes noon to shift approximately 1 hour during the day.
DST corrects for that.

Having said that: we should kill DST. The lost productivity it causes is enough reason.

On mercury this effect is so strong that the sun can be seen going backwards during a part of the day(if there was an observer there).

Re:Better way

[smooth wombat]

Sane people don't care about such ridiculous restrictions.

Tell that to the guy who fought a parking ticket because the sign used the term "12 PM". He went before the judge, explained there is no such thing as 12 PM, only 12 noon, and won his case.

Considering the anal-retentiveness of a large portion of people on here, one would think this wouldn't even be an issue. It's quite clear, AM is anti meridiem and PM is post meridiem. What time is 12 PM since it is neither post nor anti?

Re:Better way

[nedlohs]

Referencing the law as an example of "sanity" does not help your case. Yes laws are not sane, we all know that.

post since 12:01-12:59 are all PM, making noon also be 12:00 PM is unambiguous and simple and everyone knows what it means. No one cares what AM and PM actually stands for, as evidenced by you pretending to care and getting it wrong anyway.

Re:Better way

[tricorn]

That's a terrible solution. It simply guarantees that there will be even more significant problems when you do trigger that Leap Minute. Having this occur every year or two means you have an incentive to handle it correctly. Having it occur once every 60-100 years means that no one will bother handling I correctly, or will implement handling it incorrectly.

Think of a critical system that hangs for a minute rather than a second. The results would be much more damaging.

That's like fixing a memory leak by adding more memory to your system. You're just pushing problems down the line and making them more significant.

Re:Better way

[neonsignal]

for the sake of some lazy programmers

This is a failure to understand why there is a problem. How can one program in a correction which is only decided six months in advance? On an embedded platform which may have a lifetime of ten years or more.

Re:Better way

[RockDoctor]

We will. I've noticed a lot of people are already back to entering years in two digits.

In the run up to Y2K I switched to using ISO8601 date format and haven't budged. YYYY-MM-DD HH:MM:SS.ssss+TZ.... If the client then insists on using something parochial, I'll explain my reasons (date, alphabetical and numeric forms sorting into the same order) and then after they've expained why they want something parochial, I'll implement the changes they want. But they have to justify moving away from a reasonable proposition.

We were lucky that we managed to hide our Y2K bug from our customers (they came in from some 3rd-party software) by retiring the DOS version of our main product and completing the release of the windows V1 line, despite all it's bugs. But I also had a literally sleepless night babysitting a billion or so dollars worth of equipment (plus about 200 staff) as we checked out all the machines to see that there was nothing untoward happening. Cost around £2mllion.

Is there a better way?

[Pope]

No, not really. Leap seconds are a known quantity, make sure your code handles it.

Next question.

Re:Is there a better way?

[itzly]

So where's the list of the future leap seconds so I can make sure my code will handle them ?

Re:Is there a better way?

[Anonymous Coward]

They're not a known quantity b/c they do not get announced far enough in advance. 7 months is not that long of a time. And given that it is 1 second it's not significant for humans, and just messes stuff up.

Re:Is there a better way?

[msauve]

Does all of your code require deterministic knowledge of all future inputs? If so, I can't see how it can provide any real utility.

Re:Is there a better way?

[itzly]

No, but if the code is supposed to handle leap seconds properly, it needs to know in advance when they occur.

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.

Re:Is there a better way?

[Archangel Michael]

It is plenty of time. Both human and computer time.

Re:Is there a better way?

[msauve]

That's already provided.

And, before you say you need to know that before you write your code, do you also need to know in advance that "JohnQSmith/aE8&fv84%" might someday be a user's name and password? If you're writing a program which requires deterministic future time intervals, you shouldn't be using the UTC time scale.

Re:Is there a better way?

[itzly]

I don't see why you would think that any program would care about the exact password somebody is going to use. On the other hand, plenty of programs keep track of time and/or do calculations based on the time. And not every program is connected to the internet, so it can download the newest update of leap seconds.

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?

Re:Is there a better way?

[Darinbob]

The better way is just to ignore the drift. Define UTC to unrelated to the rotation of the earth or its revolution around the sun. There have been attempts to define UTC this way but is still ongoing. Ie, there's a UT1 time zone that does this and the leap second for UTC is only to keep it within a certain range of UT1.

Re:Is there a better way?

[nedlohs]

Maybe you should fu\ind a different vocation.

Does your program really need to know in advance when the user will enter the letter "a" in a name field?

Re:Is there a better way?

[Neil Boekend]

Use another time standard if it bothers you. UTC is meant to be corrected with leap seconds.
If leap seconds don't matter: use TAI.

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?

[Lord Apathy]

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

This is what I was thinking but with OS and hardware. The "slowdown" rate is a known factor. I don't see why modern system that have to be so precise don't already have this factored in. Just have them compensate for the need all the time instead of having to force the issue every few years.

Problem solved.

Re:Better way?

[itzly]

The earth's rotation isn't actually a known factor. It varies. http://upload.wikimedia.org/wi...

Re:Better way?

[CastrTroy]

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. This might cause some problems. but at least it's fault tolerant in the sense that it's not going to crash because the date format wasn't as expected when dealing with older systems or systems that were naively programmed.

Re:Better way?

[0123456]

One of the projects I worked on spent weeks just checking that the system could handle leap seconds correctly, which required getting special firmware from the GPS manufacturer which allowed them us trigger artificial leap seconds. The spec for the communication protocol that system implemented had to have special cases purely to handle leap seconds, and someone has to be on call every time it happens just in case something bad goes wrong.

They cause havoc around the world for minimal beneift. Those who care should adjust and let the rest of the world get on with their lives.

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?

[chipschap]

I've been waiting for someone to blame it on global climate change.

Re:Better way?

[GuldKalle]

Instead it will crash when one event happens at 23:59:59.8 and another happens at 23:59:60.4 (old notation). In your proposed notation, there would be no way of knowing that event one happened before event two.
In the case of DST, most systems use UTC internally, which doesn't have a notion of DST. Or said in another way, we don't adjust the base clock, we just change time zone.

Re:Better way?

[msauve]

"How about instead of setting the time to 23:59:60, the value 23:59:59 happens twice"

So, an event which should run once at 23:59:59 gets run twice? Or if you're logging event sequences, an event which happens later can be logged at an earlier time? I predict big issues with database sync in your future.

When DST happens, there is no duplication of time numbering, the time scale itself changes. 1 AM EDT is not 1 AM EST.

Re:Better way?

[bobbied]

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.

Only once every 40 years or so. Not so wrong in reality, for most applications anyway.

The alternative is pretty a pretty complex bit of programming to "do it right". Those applications that do need to be that accurate, need the complex bits of code, the bulk can just keep using the constants you learned in first grade. All this reminds me of the Y2K hoopla, which was much ado about nothing, or the DST changes of the last few decades which where rife with fear mongering for profit.

I'd say that if your application is more complex than necessary or fails to work as required, THEN you are "doing it wrong" so if 60 seconds in a min fulfills your requirements and that's what you used, you did it right.

Re:Better way?

[itzly]

That's not such a crazy thought. Melting ice can change the mass distribution, which can change rotational speed.

Re:Better way?

[Anonymous Coward]

It means that software needs to be tested for leap second compliance. Our solution to the leap second problem is very simple. We'll be moving our daily server reboots to align with the leap second. We'll simply shutdown our server software. Let the leap second hit our system then reboot. This will cause a temporary disruption to services but our users aware of it. Another solution is to do a leap second smear aka extended the seconds gently over the day but we are reliant on outside data sources and this could cause syncing errors.

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?

[Minwee]

Thanks, Obama.

Re:Better way?

[SuiteSisterMary]

Your job should have some sort of flag set, indicating completion, simply to avoid bog-standard clock issues.

Re:Better way?

[DarkOx]

It does, B runs when A says its finished. So now we are looking at the logs, and B has logged a start time before A logged its end time. What does this mean? Does it mean there is a bug in A that caused it to release the lock B was waiting for prematurely? Was everything just fine, but it happen to be clock change night? We can't tell.

23:59:60 being its on distinctly represent second would make what transpired perfectly clear, calling the next second by the same identifier 23:59:59 cases us to lose information.

Re:Better way?

[DarkOx]

Oh yes before you say anything. I realize we still have the underlying integer representation. So if we know ahead of time we need to keep that, there is an out.

Now do you want to explain to the PHP how (14205????) 23:59:59 is a time and that 142057???? + 1 is also 23:59:59 but its really a second later. Sounds like a long meeting to me.

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?

[Lord Apathy]

The slowdown of Earth's rotation is NOT a known factor, it varies. Things like earthquakes [space.com] can change the period unpredictably.

Yes, I suppose that would make my plan rather difficult to implement.

Re:Better way?

[Guy Harris]

How about instead of setting the time to 23:59:60, the value 23:59:59 happens twice.

Because that would be extremely broken as 00:00:00 - 23:59:59 is _one_ second, not two.

Broken, but POSIX-compliant.

Re:Better way?

[31eq]

The trouble is, the Internet is standardized on UTC. You can keep your system clock to TAI and use the "right" time zone files, but you have to deal with the offset between your clock and NTP, and the complexity of NTP broadcasting the leap second as it happens. (Or forego the convenience of NTP altogether, of course.)

There should be an RFC to decree that for networking purposes, we'll ignore this and future leap seconds and keep "Internet UTC" as a fixed offset from TAI. People who care about strict UTC (and it would, apparently, cost millions of dollars to fix critical military systems) can use libraries or time zones to get it. The rest of us will know our system clocks keep ticking away with minimal breakage.

What will probably happen is that we follow the leap second again, things break again, and any impetus to fix the underlying cause dies away by the time the next leap second comes around. And eventually UTC will be defined as consistent atomic time and the people who wanted UTC for what it was originally designed for will have to learn to call it something else.

Re:Better way?

[Guy Harris]

Umm... The very definition of a minute is that it *IS* always 60 seconds. Why would I be wrong if I wrote software based on that? That's like saying I shouldn't "assume" that a mile is 5280 feet. Its not really an "assumption" if that's its very definition.

Nevertheless, according to the definition of UTC, the clock goes from 23:59:59 to 23:59:60 if there's a positive leap second.

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?

[geezer nerd]

I find this confusing.

If at 23:59:59 the clock actually changes to 23:59:60 (= 00:00:00), then a second has been taken away, not added. The second denoted 23:59:59 did not happen.

I would think that to "add" a leap second, at 00:00:00 the clock should read 23:59:59.

Can someone clarify?

Re:Better way?

[techno-vampire]

Only once every 40 years or so. Not so wrong in reality, for most applications anyway.

No, Leap Seconds are added at irregular intervals to adjust for the slowing down of the Earth's rotation. The last one was added on June 30, 2012, only three years before this one. The 40 years you're referring to is how long the system has been in place. Do try to keep up.

Re:Better way?

[bickerdyke]

23:59:60 is well defined for decades and shouldn't be unexpected to anyone.

Re:Better way?

[phantomfive]

If you need a clock that doesn't have leap seconds, or doesn't go backwards, then on Linux call clock_gettime(), which is a monotonically increasing clock. On other systems, there are similar functions.

If you write software that needs to know the exact time of day, then you need to be prepared for corrections, jumping forward or backwards by hours, days, or even years as the computer adjusts itself getting a better knowledge of what the current date actually is. If you can't handle all those cases, then your software is buggy.

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]

time is stored in UT and converted for display - DST/TZ is added between stored value and displayed value. Stored time is ALWAYS in UT, that never changes. That's why databases don't fall arse over tit every time the DST switch is thrown.

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

Re:Better way?

[phayes]

How lucky for all of us who do not have any Java services then isn't it?

Re:Better way?

[bobbied]

Sorry... I'm still working on the cleanup from Y2K fallout and looking forward to Unix time running out in 2038....

Re:Better way?

[AmiMoJo]

I've got a better idea. Let's just build a big giant engine to correct the orbit of the earth to match our time system.

Re:Better way?

[msauve]

"If UTC were replaced with TAI (i.e. the same thing, without the leap seconds), I don't believe anything of value would be lost."

Of course it would. A precise, well defined timescale closely tied to the rotation of the Earth would be lost.

Civil time has for millennia been linked to sol, and many jurisdictions specifically define legal time based on UTC (e.g. 15 U.S. Code 261.) Astronomers use UTC as an easily obtained analog to the other forms of Universal Time. Sundials. Celestial navigation. Space operations (eliminating leap seconds would require code changes to the GPS system, and others).

You're certainly free to change your systems to TAI, but any proposal to remove leap seconds from UTC creates not only a redundant timescale (alongside TAI, TT and GPS), but is an attempt to force undesired change upon others. UTC was specifically created to track UT1 withing 0.9 seconds, and there are disciplines and systems which adopted UTC based on that premise.

Re:Better way?

[msauve]

If everyone would just push on the object to the east of them, we could speed up the Earth's rotation and fix this right now.

Re:Better way?

[yet another SanTiago]

How about instead of setting the time to 23:59:60, the value 23:59:59 happens twice.

This is how is leap second handled in POSIX systems, with the small different that it is not 23:59:59 but (following) 00:00:00 that happens twice.

Re:Better way?

[unrtst]

How the flying fuck is that any different from DST?

You are either scheduling your jobs by timestamp/UTC, or by something affected by a DST change.

Your example applies exactly the same to DST change events... just change the duration it took Job A to complete.

Parent is essentially saying (though he may not be aware precisely), "let's use TAI instead of UTC, and use tzdata (or similar) to account for the leap second".

That's actually somewhat like what strict unix time does: http://en.wikipedia.org/wiki/U...

actual UTC, gmtime of unixtime, unix timestamp
1998-12-31T23:59:59.00, 1998-12-31T23:59:59.00, 915 148 799.00
1998-12-31T23:59:60.00, 1999-01-01T00:00:00.00, 915 148 800.00
1999-01-01T00:00:00.00, 1999-01-01T00:00:00.00, 915 148 800.00
1999-01-01T00:00:01.00, 1999-01-01T00:00:01.00, 915 148 801.00

Going from unixtime back to UTC during the leap second is like trying to go from DST back to UTC during "fall back".
FWIW, it also does the opposite if a leap second is a removal (day ending in UTC 23:59:58.9999-)... unix time skips over that second entirely.

Do to all that, many of the standard time utilities don't actually parse 23:59:60. I'm sure there are many that do (and do not use unixtime as the underlying counter), but many of them don't. Cheap example:
$ TZ=UTC date -d "1998-12-31 23:59:60"
date: invalid date `1998-12-31 23:59:60'

Re:Better way?

[sverdlichenko]

What exactly is well-defined in current leap second nightmare? It depends on earth rotation changes, it is unpredictable, it requires keeping a database of leap seconds for all times known. Overall, it demands updating perfectly good system at random time intervals or facing inconsistent timestamps.
I really wish TAI or some predecessor of GPS timescale was chosen for computer timescale. Leave astronomic events to astronomers.

Re:Better way?

[complete loony]

If your machine is not connected to an atomic clock, your measurement in UTC is likely to be slightly off anyway. So tweaking the rate of time passing so that every day has the same number of seconds is a reasonable compromise. I remember hearing that google do this in their data centres.

If you do have a local atomic clock, record timestamps against TAI and convert to UTC. But even there you have to deal with clock drift, though the error bar should be much smaller.

Re:Better way?

[msauve]

Really? UTC is defined by a clearly written normative standard, ITU-R TF.460-6. If you don't consider that well defined, you have no understanding of how standards work.

Re:Better way?

[sverdlichenko]

How many seconds would be between 00:00:00 January 1st 2015 UTC and 00:00:00 January 1st 2050 UTC?

Re:Better way?

[msauve]

How many emails will you receive between the current moment and the end of the year? It's not deterministic. Deal with it.

Re:Better way?

[aXis100]

I used to build & configure production reporting systems for industry, and the increase in complexity on the math was freaking painful when you had to take in to account daylight savings. Instead of assuming 24 hours in a day, you would always have to calculate "day end minus day start".

These methods would handle leap seconds just as well, but the cost to performance is massive for such a rare event.

Re:Better way?

[sverdlichenko]

Exactly my point. UTC is well-written standard, targeted to users in need of timescale matching astronomic time with sub-second precision, and their requirements are greatly different from ones IT have. Majority of computers do not give a shit about how Earth is rotated at given point of time, and that which care are controlling telescopes or ICBMs, where 0.9 seconds difference may be to big anyway.
Timescale is an abstract concept, not a real world event series like email, and as such, it may be designed to fit whatever it purpose is. IT needs uniform, monotonic and deterministic time, and UTC fits badly, although better than local time with DST adjustments or some hypothetical timescale with floating second length.

Re:Better way?

[msauve]

You were doing it wrong. If you do it right, you use UTC (or even the local *ST or Unix time) for everything. Conversion to/from *DT is cosmetic, and only occurs in the UI.

Re:Better way?

[msauve]

So, quit complaining, stop being lazy, and convert your systems to use TAI or GPS or TT.

BTW, UTC, even with leap seconds, is perfectly monotonic, you apparently don't understand the meaning. You say IT requires deterministic time, but don't say why? If you need an event to happen X seconds in the future, you can do that. If you need an event to happen at a specific time in the future, you can do that, too. Leap seconds get in the way of neither, except for the lazy. It's a simple matter of picking the right timescale for the need.

Re:Better way?

[sverdlichenko]

You apparently don't understand that "monotonic" makes only one of the three "uniform, monotonic and deterministic". Deterministic is needed to write simpler programs and have less room for error. There is only so much programmers' power and if it is used to fight timescale issues, other, more useful tasks are delayed. Last leap second wasted a lot of man-hours for nothing.
And stop telling me what to do unless you pay me.

Re:Better way?

[msauve]

You're doing it wrong.

Re:Better way?

[petermgreen]

That works if all you care about but it breaks down as soon as you have to handle future and regularly scheduled events and/or deal with external constraints that are defined in term of local time.

For example suppose you divide the day into shifts, and the shifts are defined in terms of local time (and have been since long before your computer system came along). Once a year you will have a shift that is an hour longer than normal and once a year you will have a shift that is an hour shorter than normal. That means many calculations can no longer assume shifts or "days" (where a "day" is a group of shifts) of constant length.

And then theres the fact you can't reliablly convert future local times to UTC because DST rules are at the whim of the legislature. If your users schedule a meeting at 9am local time in a few months time they will expect it to stay scheduled at that local time even if the government changes the mapping from local time to universal time in the time between the meeeting being scheduled and it happening. Have fun with meetings between users in different jurisdictions.

 

Re:Better way?

[certsoft]

While GPS receivers are supposed to use 23:59:60 a receiver I was testing the last time there was a leap second did indeed generate 23:59:59 twice. Our software now accepts either. We're getting started on a new system this year, hopefully we'll get a selection of GPS receivers wired up to see what they do on June 30th.

Re:Better way?

[Neil Boekend]

Why doesn't NTP give both UTC and TAI (or GPS)?
Or devise a similar system with as only difference that it gives TAI or GPS.

Re:Better way?

[AmiMoJo]

That's probably why satellite systems don't use leap seconds. GPS time is currently 16 seconds ahead of UTC because of this.

Re:Better way?

[msauve]

I'm so sorry you're forced to deal with reality.

Re:Better way?

[SuiteSisterMary]

How do you deal with, say, NTP update fixing your clock drift?

Personally, I like the idea of a 'second' being of variable length far better than shoehorning a '60' into a field that's clearly defined as '0 to 59'.

Make leap miliseconds

[NotInHere]

Then engineers build their systems so that they work with leap miliseconds, as otherwise they would fail more often. If your system fails only every 4 years and then only for a few seconds, you won't invest in fixing the problem. If the event occurs more often, then you're forced to.

QA solution to leap second issues

[SuperKendall]

There should be a leap second every month, followed by elimination of a second the following month. That way all code would quickly be adapted to work correctly with leap seconds.

Then of course you have to program to handle the months you don't omit a second because you really wanted the leap second to take...

Re:QA solution to leap second issues

[camperdave]

Why do that? Why not just fix the code to properly handle leap seconds and skip seconds the way they are defined now. Or, if it so all fired important, use TAI instead of UTC and use PTP instead of NTP.

Dammit!

[Chillas]

Dammit, I'll be working! I better get OT for this.

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.

Re:Man vs Machine?

[TitusGroan8856]

>but you either need to download a special program to make the changes or edit the registry by hand... Or you need to learn how to use .cmd/.bat files with the system scheduler or at command.

Re:Man vs Machine?

[Obfuscant]

There is already a service running that deals with time. Why should I schedule another one to do the same thing?

Re:Man vs Machine?

[sverdlichenko]

Why exactly computers need to know precise moment of sunrise? My web server does not care.

Re:Man vs Machine?

[petermgreen]

Personally I suspect that slight variations in the length of a "wallclock second" would be much less disruptive than a special case 22:59:60 time which can't be represented in many time formats and is sufficeiently rare that problems with it's handling are likely to go unnoticed during testing.

Yes a mechanism for adjusting the speed of clocks would be needed, but we already have such mechanisms to deal with the crap tolernaces of most local clocks.

Re:Man vs Machine?

[mwvdlee]

The frequency of your incomming AC isn't quite the stable 50/60Hz but they tend to correct it so it averages out to perfect 50/60Hz on a long enough time scale. As I understand it, they use this same type of correction to account for leap seconds, which help keep a lot of cheap clocks running accurately.
This is a story I heard over a decade ago from an electronics teacher, don't know if it's actually true.

Re:Man vs Machine?

[mwvdlee]

Good to hear. What is your website URL?
I'd like to place an order right in the last second of June for a product with a discount ending in June, then sue you for not applying the discount even though the order was placed on June 30th, 23:59:60 UTC (which is probably somewhere in the middle of the day for you).

Re:Man vs Machine?

[michelcolman]

Yes, why can't we just decree that, instead of 12:00:00 UTC on two very specific days of the year corresponding to the time when the sun is precisely overhead some specific point in Greenwich, it will now be precisely overhead some point a few hundred meters east of that point (still in Greenwich)? Or, for all I care, over Southend-on-Sea (several hundred years from now)? WIll that make any difference at all in people's lives? People wielding sextants can just compensate for the difference, I don't see how that would be a problem. It would be a small correction that only changes slowly over time.

At some point we can make time zone changes without touching UTC. Time zones have been shifted so many times in the recent past, I don't see how it could be a huge problem to make such a change once every few hundred years. And computers should be using UTC anyway, converting to and from local time for user display and time entry only.

Re:Man vs Machine?

[Eunuchswear]

When diagnosing problems that affect more than one machine its very useful if the times in the log files match.

Re:Man vs Machine?

[sverdlichenko]

Oh sure, bring it on.Your order confirmation will show perfectly good Jul 1st timestamp. This is if my website was taking any orders at all, not everyone want to sell you something :)

simple!

[JustNiz]

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

We just need to make each second last a very little bit longer.

Re:simple!

[camperdave]

You cannot redefine the second without rewriting all of science.

Re:simple!

[david_thornley]

And thus making the meter a very little bit longer (the meter is defined in terms of the second).

Re:simple!

[JustNiz]

maybe it will finally come together better.

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:here is the draft set of possible options

[0123456]

People need to _think_ about the function of time in their applications

Yeah, like that's gonna happen.

and stop pretending like it's a simple problem or that it can solved for you by tweaking international standards.

99% of of software expects a monotomically incrementing time which has 60-minute hours and 60-second minutes. Having the detault time not meet those expectations is moronic, and potentially catastrophic in a world so reliant on computers.

Re:here is the draft set of possible options

[yet another SanTiago]

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

That is not correct. POSIX speaks about SI seconds, it just specifies that 'unix time' is *approximate* number of (SI) seconds from the start of the epoch computed by a formula from date/time. When a leap second happens, the difference of this approximation from the exact number changes by one second and unix time experiences discontinuity (leap backwards).

tyson

[fche]

Solution there, it seems to me, is to inhabit unchangeable-spin planets.

Re:tyson

[smoot123]

Deal. Let's start building a Ringworld.

Re:Earth not _turning_ slower, but already is slow

[Russ1642]

The problem is that you don't understand it.

Accuracy of Tools and Software

[lsllll]

I'm pretty sure NASA would have to account for all of these additions, but do we live in the same precision world as does NASA? Do command lines like "date +%s" historically count these seconds?

Investment oportunity

[Trachman]

At some point the earth will stop spinning.

The one who will build a forecast model will know which side of the earth will be .... "sunny way up".

Appropriate investment decisions can be made to purchase a land in the twilight zone, where is not too hot and not too cold.

Some sources say, that earth is slowing down 1.7 milliseconds every 100 years. However the last leap second adjustment took place in 2012, http://en.wikipedia.org/wiki/L...

Anybody know a quick and dirty way, a good formula, that would tell us when the earth will really stop rotating?

Re:Investment oportunity

[fche]

"Anybody know a quick and dirty way, a good formula,"

Why sure. We demonstrate the amazing power of DIVISION:

24 hours
-----------------
1.7 ms/100 years

= 5.0823529e+09 years

Re:Investment oportunity

[Trachman]

Ok, Can you calculate the slow down, if ajdustments were done as follows: one in 2012 next one in 2015, basically every three years.

Re:Investment oportunity

[geantvert]

According to http://en.wikipedia.org/wiki/T...

> If other effects were ignored, tidal acceleration would continue until the rotational period of Earth matched
> the orbital period of the Moon. At that time, the Moon would always be overhead of a single fixed place on
> Earth. Such a situation already exists in the Pluto–Charon system. However, the slowdown of Earth's
> rotation is not occurring fast enough for the rotation to lengthen to a month before other effects make
> this irrelevant: About 2.1 billion years from now, the continual increase of the Sun's radiation will likely
>cause Earth's oceans to vaporize,[11] removing the bulk of the tidal friction and acceleration. Even without
> this, the slowdown to a month-long day would still not have been completed by 4.5 billion years from now
> when the Sun will probably evolve into a red giant and likely destroy both Earth and the Moon.

Anyway, your formula is wrong for several reasons. The first being that slowing down the earth rotation does not reduce its day length but increases it.

So assuming that the rate of 1.7 milliseconds every 100 years will remain constant, daytime will increase by 17s every million years. That's about 1700s ~ 1/2 hour every 100 Million years or 5 hours every 1 billion years.

So when the Sun will destroy earth in 4.5 billion years, one (hot) day should take about 24+4.5*5 = 46.5 hours.

Re:Investment oportunity

[confused one]

It's not going to stop spinning. What will happen, though, is the Earth will eventually become tidally locked with the Moon. The pair will continue to rotate around the barycenter. Unfortunately, the Earth and Moon may be engulfed by the expanding Sun before this happens.

Re:Investment oportunity

[fche]

Thank you for your correction.

Re:Investment oportunity

[geantvert]

The more I think about it, the more I feel that this leap second system is bogus on the long term. The problem is that the 1.7 milliseconds are cummulative.

This is of course not true but for the sake of simplicity, let suppose that a second was defined according to the day length of 1900.

Around year 2000, so after 100 years, each day is now 1.7 ms longer so a whole year is 365*1.7ms = 0.62s longer. A leap second will be required every 1.6 years on average.
Around year 2100, so after 200 years, each day is now 3.4 ms longer so a whole year is 365*3.4ms = 1.24s longer. A leap second will be required every 0.8 years = 9 months on average.
Around year 2200, so after 300 years, each day is now 5.1 ms longer so a whole year is 365*3.4ms = 1.86s longer. A leap second will be required every 0.53 years = 6 months on average. ...
Around year 2900, so after 1000 years, each day is now 17ms longer so a whole year is 365*17ms = 6.2s longer. A leap second will be required every 0.16 years = 2 months on average.

There is of course no easy solution to that problem. Ideally, the second itself should be redefined regularly according to the day length.

Re:Investment oportunity

[geantvert]

UTC sucks. I am going to switch all my computers to TAI

Re:Investment oportunity

[jdschulteis]

At some point the earth will stop spinning.

The one who will build a forecast model will know which side of the earth will be .... "sunny way up".

Appropriate investment decisions can be made to purchase a land in the twilight zone, where is not too hot and not too cold.

Some sources say, that earth is slowing down 1.7 milliseconds every 100 years. However the last leap second adjustment took place in 2012, http://en.wikipedia.org/wiki/L...

Anybody know a quick and dirty way, a good formula, that would tell us when the earth will really stop rotating?

The Earth will likely still be spinning when the Sun becomes a red giant, boils away the atmosphere and oceans and turns everything all melty, so the real (long-term!) investment deal is in O'Neill colonies.

TAI

[GuldKalle]

You could use Atomic time, which is basically UTC but without leap seconds.

Re:Earth not _turning_ slower, but already is slow

[Archangel Michael]

Every large earthquake changes the rotation speed. The big 8.x one a few years ago, the one with the Tsunami, that one significantly changed rotation.

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.

Easy peasy (lemon-squeezy)

[fahrbot-bot]

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

Decrease the radius of the moon's orbit.

time running backwards?

[X10]

Will my server have "time running backwards" errors tonight? If so, I'll have problems with dovecot mail tomorrow.

Worked in the cartoons

[Tablizer]

How about everybody just run the same direction for a few minutes to speed Earth back up?

Re:Worked in the cartoons

[Russ1642]

XKCD has it covered: https://what-if.xkcd.com/26/

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.

Mario Kart

[geantvert]

61s in a minute! I will definitely try to beat my best laptime on Mario Kart Wii.

Re:Mario Kart

[geantvert]

or maybe I shall pay a visit to the closest nuclear power plant to see it explode. I was so frustrated at Y2K

"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

[amorsen]

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.

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

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.

Re:Fix NTP

[camperdave]

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.

Predicting earthquakes, land slides, massive storms, icebergs, and other events that alter the rate of rotation of the Earth by looking at the stars is a job for astrologers, not astronomers. Also, by definition, TAI and UTC differ by an integral number of seconds, and they currently differ by 35 seconds - far more than your battle inducing 0.9 second threshold.

There are three important time systems in play here. TAI, UT1 and UTC. TAI is a count of SI seconds based on atomic clocks situated around the world. UT1 is the count of "solar" seconds based on the angle of the Sun to the Prime Meridian. Because it is based on the rotation of the Earth, which can vary for a multitude of reasons (earthquakes, icebergs, etc), UT1 "seconds" are variable in length, However, unlike TAI there will always be exactly 86400 seconds in a day.

UTC is a compromise time scale. It uses SI seconds, like TAI, but there are occasional adjustments made so that it remains synchronized to within one second of UT1. These adjustments come in the form of leap seconds (or skip seconds).

The International Earth Rotation and Reference Systems Service (IERS) has the responsibility of adjusting UTC. The last minute of the last day of the month can be lengthened or shortened by one second in order to keep UTC and UT1 in step. By agreement, the first preference is to adjust in June or December. The second preference is to adjust in March or September. So far, there has been no need to adjust using a skip second, or to adjust in any month other than June or December.

Re:Fix NTP

[jcdr]

PTP is mainly designed to work well on LAN. While it can be used on WAN, there is currently no equivalent to the large quantity of open NTP servers on the internet. Thanks to the open NTP servers, NTP bring service comparable to GPS regarding time synchronization source, something that PTP is unable to do if you don't have access to particular master PTP node, usually connected to a GPS or a NTP server.

Maybe one day PTP will have a range of open master node on the internet, but AFAIK this actually not the case. It should be noted that when used over WAN, PTP is not better that NTP from the precision point of view.

Finally PTP don't solve all issues. To have a reliable actual time and time processing capabilities everywhere around the world, NTP, GPS and PTP should be extended to broadcast the updated historic leap second table and the updated timezone database, as well as the UT1 frequency offset. With all the additional information, any devices could use the right time for his purpose.

Re:Fix NTP

[amorsen]

I meant UT1 instead of TAI in that sentence. Sorry.

I do not care if they predict it in advance. Just issue a leap second in 5 years time if it looks like it will be necessary within 6 months. Yes, UT1 will drift away from UTC by more than 0.9 second, but who cares? It will never be far enough away for anyone other than astronomers to notice, and astronomers use UT1 anyway.

The best solution, of course, is to simply kick the astronomers out of civil timekeeping entirely. Bring them in for a consultation every thousand years and change time zones then, if necessary.

Re:Fix NTP

[camperdave]

Again with the Astronomers? Astronomers have nothing to do with time zones. Time zones are political, not scientific. So is UTC when it comes down to it. However, it was not designed the way it was on a whim. So we just need to buck up and switch computers to TAI.

Re:Fix NTP

[amorsen]

Time zones are fine. Astronomers are not to blame for those. Astronomers ARE to blame for the mess that is UTC. Give them UTC and UT1, and move all civil time to TAI with time zones. Change time zones when the offset gets too large (which is pretty large, considering that China does just fine in a single time zone -- they somehow survive that the sun is not precisely above them at 12.)

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.

Re:Do the impossible

[TheCarp]

Hit it? why? The earth is already being slowed down by tidal interactions with the moon. we just need to slow the moon down until it drops under geosynchronous orbit, then its tidal bulge will move faster than our rotation and rotational energy will transfer from the moons new orbit to earth's rotation.

There are a couple of minor downsides....like massive increases in the amplitude of the tidal bulge, but moon missions will require a lot less delta v...... of course, it also means the moons orbit will progressively shrink.

Maybe put it in geosync and just try to keep the day length where it is?

KISS

[sjames]

For the vast majority of cases, leap seconds shouldn't be a problem (or even important). Just note that the clock is wrong and use the built in OS functionality to adjust the clock. (in other words, on a well maintained server, do nothing special)

For things that need a constant time base but not a persistent one, just count the ticks and call it good.

For the really hard cases, we probably need a time base that is simply the number of seconds from a defined base. Then maintain a simple table in the public domain containing the correction to the other time bases. Just select the greatest entry that is <= the current time and apply the correction to derive the adjustable time value.

oblig Simpson's joke:

[Anonymous Coward]

"precisely timed money transactions could go astray"

oh, won't someone PLEASE think of the frontru..., er, I mean "high frequency traders providing liquidity"!!!

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

[Sowelu]

Making the generous assumption that this is a brain slip and not a troll, seconds don't normally go up to 60. They stay in the range of 0..59, which means there's sixty of them. Counting from 0 to 60, including the 0, gives you 61 seconds in that minute.

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

Leap seconds work just fine

[dwheeler]

Leap seconds work perfectly well for most situations. If you need precision monotonically-increasing seconds, use TAI time (or "GPS time", which is at a fixed offset from TAI). Leap seconds keep atomic clocks and the real world reasonably synchronized; any other approach will have its own problems.

The Problem with Time Zones

[chuckugly]

Explained here.

Re:Earth not _turning_ slower, but already is slow

[TFlan91]

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

Better way to solve that problem

[bickerdyke]

Choose your timescale wisely. Use UTC where it's important that "time" matches some random astronomic phenomenas, and use TAI where consistency matters.

Re:Do the impossible

[datavirtue]

Just divert it to pass at the proper angle pulling the earth's rotation faster...no need to hit.

Re:Earth not _turning_ slower, but already is slow

[camperdave]

There are regular intervals at which leap seconds *CAN* be applied (The last day of March, June, September and December may be one second longer or shorter than other days). However, leap seconds and skip seconds are not always applied. They are irregular because the turning of the Earth is irregular.

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

[camperdave]

The protocol allows for a "skip second" as well as a leap second. The clock could legitimately go 23:59:57, 23:59:58, and then 00:00:00.

Re:Earth not _turning_ slower, but already is slow

[ihtoit]

uh... it is slowing down, by an average of about a millisecond a year, due to tidal friction against the gravitational pull of the Moon.

Re:Earth not _turning_ slower, but already is slow

[Livius]

the problem is not that Earth is slowing down, but that the speed is slower

Try thinking that through a little more carefully.

Pope Gregory XIII has you beat

[trout007]

He skipped 10 days to make the calendar line up with the equinox.

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

[Russ1642]

I wonder how many programmers are going to complain that they only coded for leap seconds and never bothered allowing for the reverse. It'll happen one day.

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.

Re:Earth not _turning_ slower, but already is slow

[camperdave]

Addendum: The last minute of the last day of any month can be lengthened or shortened by one second. However, there is a first preference of June or December, and a second preference of March or September.

Re:Slowing DOWN?????

[ls671]

> So, what do you intend to do during that extra second added to that day? Well, you may want to fix your systems.

Nah, I am just going to going to set my watch during that extra second.

Time to commit...

[John Guilt]

...a crime lasting less than one second---it legally won't exist. (Note: this is not at all true.) (It's based on a short New Zealand film I saw decades back in which a man is released because it turned out that when a relevant law were changed there were a gap between the new and old laws' domains, and his offence was in the gap. He and a mate went on to hijack a bus and charge people extra to take them exactly where they went, which proceeds they wanted to use to start a mushroom farm.)

Re: Slowing DOWN?????

[ls671]

1) be ready when your watch shows 00:00:00
2) wait until it shows 00:00:01
3) press button
4) now watch shows 00:00:00

elapsed time: 1 second

did you ever own a watch?

Beliebe

[sharknado]

Eject all Beliebers into space...lower mass = increased rotational velocity = no need for leap seconds.

Perhaps you've heard of GPS

[chromaexcursion]

GPS doesn't directly need leap seconds, but it relies on astronomical calculations that do.
I write software that deals with leap seconds. I don't write the stuff that actually calculates them, but I have to make sure not to break it. One of the mottos of the company I work for is "it is rocket science".
A second is a small enough margin of error to be allowable. Most time systems are based on seconds, so that's the smallest reasonable choice.
For the jokers. An error of 1 minute would be 1 nautical mile (almost 2 km). Which is 1 minute of latitude (60 minutes in a degree). Funny how minute and nautical mile are the same.
I'm an astro geek, and a sailor, don't piss in my yard.

Re:An even better way . . .

[kwbauer]

Uh, you mean the system of telling time that is based on seconds, minutes, hours, etc.?

Extra time

[kevingolding2001]

So, what do you intend to do during that extra second added to that day?

Well there's this novel I've been intending to write but haven't got around to it yet.

Re: Slowing DOWN?????

[mwvdlee]

Because all watches work exactly like your digital calculator watch?

Re: Slowing DOWN?????

[Hognoxious]

What button?

See the invisible

[Talderas]

Row row fight the power?

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

   

What about syncing dynamically?

[martinfb]

There are a few thoughts along this line:
- Base time on a basic cosmological constant - perhaps the period of a basic elemental or physical constant.
Then, we regularly calculate the change in Earth's rotation and factor that into the daily calcs for sunrise
and sunset, and live accordingly.
- Screw ANY constant. Base 'regular' time on a percentage of actual Earth rotation, constantly updating
common cronographs (watches), dividing the day up into set portions. Perhaps mid-day is when the sun
is directly overhead (like it theoretically is now). Thus, mid-day -to- mid-day period changes at the
current rate of 1/1000 of an hour. When the rate changes, as time will gradually do (barring a
catastrophic event), lives can also gradually follow the change.

What about syncing dynamically?

[martinfb]

We would likely need to keep 2 clocks: One based on a constant period, and another based on events related to Earth's rotation.

tyson

[martinfb]

Cool! How long would it take to get there? ;-)

How to eliminate the need for leap seconds

[ck512ax]

Strap some big rockets on the earth around the equator and let them speed it up. Bob