June 30th 2012 will be 1 second longer: 23:59:60

http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat

by sirwitti • 14 years ago

297 82 14 years ago

hpiers.obspm.fr

JonnieCache2• 14 years ago

At midnight on NYE 2008/9 we dialed up the speaking clock, and there actually was an extra beep. It was pretty cool, and we felt a brief moment of existential nausea when we suddenly felt our size in relation to the solar system.

(I'd like to point out that after that we did go to a massive party.)

27182818284• 14 years ago

I think this announcement is a bit dated. I thought it went back into debate?

oasisbob• 14 years ago

Perhaps you're thinking of the proposal to abolish the leap second entirely?

http://www.bbc.co.uk/news/science-environment-16625614

The parent link is to the authoritative Bulletin C, hard to imagine that it's wrong.

excuse-me6• 14 years ago

No it was rejected.

Although it's always possible that the USA will unilaterally ignore cheese-eating surrender monkey time and adopt "freedom time"

sp332• 14 years ago

It was deferred, not rejected. And France is on the same side of the issue as the USA (they don't like leap seconds).

jessriedel• 14 years ago

The wikipedia article on International Atomic Time is worth reading. http://en.wikipedia.org/wiki/International_Atomic_Time

rayanm• 14 years ago

That should give me more time to submit a conference paper on June 30.

DanWaterworth• 14 years ago

I wonder how many people will be woken in the middle of the night by bugs caused by this.

freehunter• 14 years ago

At least on Cisco systems, you can add a leap second [1], and at least on my network the tolerance is set at 5 minutes. So network time should still be working. For clients that might not know how to deal with a leap second but still poll network time, I only see issues in the rare case that the client polls the server at exactly 23:59:60. In that situation, they might poll back again to grab a new time thinking it's wrong.

Of course there will always be outliers and poorly coded applications that rely on time, but at least it's not a Y2K style situation.

[1] http://www.cisco.com/en/US/tech/tk869/tk769/technologies_whi...

scorpion032• 14 years ago

Yup. Gain 1 second. Lose hours debugging the problems that causes. Not worth it. :P

dllthomas• 14 years ago

Amusing, but the issue is not really gaining or losing seconds, but keeping the clock synched to the rotation of the Earth. As long as we're going to all the trouble of dealing with timezones to make sure our wall clocks have a roughly consistent relationship to when the sun is in the sky, we should be doing this kind of thing as well.

Cushman3• 14 years ago

This is definitely something you should worry about if you rolled any of your own time code. The POSIX standard is consistent across days, including leap seconds. That means that your Unix timestamp will jump back a second: it will go from 1341100800.9...[0] to 1341100800. If you're relying somewhere on seconds being continuous, or on a one-to-one mapping between timestamps and seconds, this could fuck things up.

Although 1341100800 refers to two seconds, when converting to UTC it should always become 00:00:00. Your implementation may not be conforming to the standard, though. Make sure to test.

(I'm sure if you rolled your own time code, you already know about this stuff. Probably other folks are curious though :)

[0] I think this is the second we're talking about, not positive though.

arohner• 14 years ago

I've found or read about bugs in nearly every stdlib time library I've ever worked in, except Joda time[1].

If you rolled your own, you should worry more, but you should still think about it even if you didn't roll your own.

[1] Joda is awesome, and by far better than any other time lib out there, but even they have bugs they're fixing in JSR310 (http://jcp.org/en/jsr/detail?id=310)

rmc3• 14 years ago

Well it happens every 1½ years or so…

Splines• 14 years ago

Me too. I'd be really interested to hear their story. Has anyone been involved with fixing a system that would have been provably broken by stuff like this (and other things like Y2K)?

Bonus points if you were working on critical public infrastructure like a nuclear power plant.

Worst thing in recent history that I remember is the Zune's leap-year bug: http://en.wikipedia.org/wiki/Zune#First_generation

heliodor• 14 years ago

Not many. Which begs the question, why is this the top link on HN?

IsTom2• 14 years ago

People will look at each other and ask: "I always use CLOCK_MONOTONIC, do you?"

molmalo• 14 years ago

Nice! One more second before my next birthday! Oh, I've lost a few more writing this... Cant we add an hour or so, so I can take a nap?

SeoxyS• 14 years ago

I wonder what the impact is on computers. Will your server know to add another second, or will it just lose sync and be one second off for the rest of times?

throwaway64• 14 years ago

it will just sync via NTP, and assume the "difference" was regular clock skew.

mbq2• 14 years ago

At least UNIX time is sane enough not to count this madness, so all time differences are objective; only one timestamp value will ambiguously mean (-1):60th and :00th second in UTC.

aphyr4• 14 years ago

POSIX time will jump discontinuously backwards after the leap second, counting:

59.50 59.75 60.00 60.25 60.50 60.75 60.00

Or, if your clock implementation is not POSIX-compliant but follows Mills' paper instead:

59.50 59.75 60.00 59.25 59.50 59.75 60.00

It gets weird, though: since this information was only made available recently, your computer may not know the leap second exists. In that case, its upstream NTP servers will jump and the local ntpd will slew the clock smoothly over the discontinuity, IIRC.

OTOH, if your system is aware of the leap second and if you're using the system clock to calculate intervals (i.e. t2 - t1), expect possibly negative or zero intervals over this timeframe. If you're calculating rates over a roughly 1-second interval, divide-by-zero bugs are definitely possible.

On a related note, does anyone know what the Oracle and OpenJDK JVMs do with respect to System.currentTimeMillis? They claim it's number of seconds since the epoch, which would imply this timer will not encounter discontinuities. The only ways I can think of to achieve that are by reading the system clock state to look for the leap insert/del/doublecount flag, or read a copy of the leap second table.

[edit] You may be asking, "Why would anyone use a system of time in which two numbers could refer to the same instant, or one in which a given number could refer to no time at all? Why not use a time system in which you could subtract two times from each other to get the interval between them? Or hell, even a time system where time always increases, you know, so we could order events.

The closest thing we have to such a time scale is TAI (http://en.wikipedia.org/wiki/International_Atomic_Time), which is what most computer systems like to pretend their clocks are: "the number of seconds since an epoch".

UTC and POSIX time are adjusted, relative to TAI, to keep the number of seconds in a given day at a nice "easy" 86400, which is why we're in this mess. Given that it takes plenty of math to translate a number like 1339696998.435347 into a human-readable date, I think our computers should just be keeping TAI to begin with and make the whole process easier on ourselves; but so many systems assume UTC or POSIX time that we're stuck with it.

Cushman3• 14 years ago

I think you're glossing over the fact that POSIX time was designed to correspond to UTC without needing additional information. Since leap seconds vary in response to solar and geological phenomena, converting from TAI to UTC requires an up-to-date lookup table, while the possibility of out-of-order times can be accounted for in code. I think that's the reasoning behind it moreso than "math is hard".

aphyr4• 14 years ago

You're right; it was designed to make interoperating with UTC easier.

Converting from TAI to UTC requires a lookup table; but consider that this is already a problem: your local clocks almost always keep time in seconds, not UTC. In order to keep UTC/POSIX time, it needs regular updates from the network (NTP) or shipping around a lookup table. This probably made more sense before large-scale use of NTP, but nowadays I don't know anyone who syncs their clock to a UTC source.

UTC is in general fucked because two different systems, depending on the state of their lookup tables, may not agree on what time a given number represents. This is an especially big problem for embedded systems which can't receive regular updates; consider that a UTC device manufactured in the 70s may disagree by up to 30 seconds with a modern UTC clock.

The easiest resolution to the problem is likely to drop leap seconds from UTC altogether; at which point POSIX, TAI, and UTC can proceed in lockstep corrected by a fixed offset. [1] Then we can use fixed lookup tables to compute relationships for the period where we were using leap seconds.

[1] I think. Need to check SI/NIST on this.

masklinn• 14 years ago

> UTC and POSIX time are adjusted, relative to TAI, to keep the number of seconds in a given day at a nice "easy" 86400

yes, technically POSIX time is defined not as a number of seconds since epoch, but as 86400 * (number of days since epoch) + (number of seconds since last midnight)

aardvark179• 14 years ago

Java hedges its bets. System.currentTimeMillis refers you to the docs for java.util time which states

"Although the Date class is intended to reflect coordinated universal time (UTC), it may not do so exactly, depending on the host environment of the Java Virtual Machine."

and further down in notes on possible ranges of return values

"A second is represented by an integer from 0 to 61; the values 60 and 61 occur only for leap seconds and even then only in Java implementations that actually track leap seconds correctly. Because of the manner in which leap seconds are currently introduced, it is extremely unlikely that two leap seconds will occur in the same minute, but this specification follows the date and time conventions for ISO C."

aphyr4• 14 years ago

Yeah, I was reading the same docs with confusion. My coworker cscotta dug down into the source. Oracle's JVM on Linux just calls gettimeofday(), which means System.currentTimeMillis will go all wonky during leap seconds. Ah, documentation. :D

vlisivka3• 14 years ago

NTP can adjust clock by minutes. User can adjust clock by minutes, days, months, or even years.

EDIT: Simple time torture script is added:

  for((I=0; I<100; I++)); do date --utc --set=@$(( `date --utc +%s`+1 )) ; date --utc --set=@$(( `date --utc +%s`-1 )) ; done

acomjean2• 14 years ago

Thank goodness I don't have to work on time anymore. Zulu time, sidereal_time, UTC, GPS Time... Phone calls from work at odd hours..

I do like GPS time. It keeps going at a constant rate like all good time should. Time differences are easier in GPS, you don't have to worry about pesky leap seconds....

Sidereal time is the most interesting from a cosmic sense.

rmc3• 14 years ago

This happens about every 1½ years. It is also the reason why posix/epoch time is not the number of seconds since 1970.

mschalle• 14 years ago

I'm guessing my iPhone alarm will break again?

tazzy531• 14 years ago

How Google handles leap seconds (by lying to the software):

http://googleblog.blogspot.com/2011/09/time-technology-and-l...

Trufa• 14 years ago

That is pretty awesome if you ask me!

adamsmith• 14 years ago

Why use cosine to interpolate v.s. a linear smear?

excuse-me6• 14 years ago

Very good question.

I can only think it's too randomize it a little so you don't end up changing clocks only by powers of 2 and showing up some weird bug.

ajross• 14 years ago

The cosine is pretty much the perfect interpolation function when you want the derivatives to be zero at the boundaries. It's by definition frequency-bound (to itself, of course). It's derivatives are defined and continuous to any degree you want. And it's easy to express and understand. You pick other functions only when it's too expensive.

ThisIsADogHello• 14 years ago

Probably to minimise the error inbetween updates. If the clock rate changes suddenly, then after that moment, any clocks based on the old rate will become increasingly wrong. but, if the skew starts off slow, begins to change rapidly, and then slows and stops again, then clients won't need to be immediately aware of the clock skew and will be less wrong.

bajsejohannes• 14 years ago

Does anyone know where you can subscribe to future leap second announcements?

acomjean2• 14 years ago

We were in the US so we used to get it from the Naval observatory.

http://www.usno.navy.mil/USNO/time/master-clock/leap-seconds

they get if from IERS

http://www.iers.org/

They issue leap second guidance to about 1 year in the future. They adjust typically twice a year as needed (Jan 1 and July 1).

dhimes2• 14 years ago

Was looking up mine while you posted yours. Yours looks like it gives more advance notice. I'm religiously opposed to deleting posts, however, so I'll just upvote yours.

excuse-me6• 14 years ago

I like the name "International Earth Rotation Service" - I always picture some dusty cavern with a giant brass gear wheel and a little old guy coming in with a key every day to wind it up.

dhimes2• 14 years ago

I received word through a listserve from the coastguard http://cgls.uscg.mil/ Once you agree to the security whatever go to 'hosted groups.' I subscribe to 'Notice Advisory Navstar Users,' which issues reports about GPS updates. They notified us 30 May 2012.

Edit: acomjean looks to have a better source (but if you are looking to subscribe to the Local Notice to Mariners in your district, which I strongly encourage if you boat on the ocean, my links will get you there too!).

RedwoodCity• 14 years ago

I look forward to the extra second of sleep.

cdooh2• 14 years ago

It's only one second, while quite interesting I don't see why this matters

excuse-me6• 14 years ago

You mean why it matters that we have leap seconds (it doesn't and they should be abolished) or why the news of it matters (because a 1000 crappy time implementations are going to walk off the end of buffers and do weird things) ?

cdooh2• 14 years ago

Why it matters that we have leap seconds. It is just one second and it happens randomly based on several factors

iRobot• 14 years ago

Why was this down-voted? I agree with the poster, and as far as I see, I wake up and everyone's clock is 1 second wrong, why precisely should I give a frig about this and how is the world going to end or change due to the clock going from :59 to :00 instead of :60 or anything being a second out?

marshray• 14 years ago

Picture yourself riding an elevator in a tall office building, when the clock strikes midnight. The elevator controller has its time synced via posix time. The controller schedules when to stop running the elevator motor by reckoning from its last known position and projecting forward according to its estimated speed. Normally this calculation is performed 10 times a second so it's a smooth transition.

But when the clock jumps back abruptly by 1.0 s, the controller gets confused. Its next control loop update cycle is now scheduled 1100 ms into the future instead of the normal 100 ms period. This delays the motor shutdown signal and even causes the controller to miss the top-of-position sensor. The elevator car slams into the roof of the building. The cable snaps and all passengers contemplate Einstein for 10 s as the elevator car freefalls to their certain doom.

Well they would have, except that cable elevators have had mechanical safeties for a backup system since the 19th century.

OK, so instead:

Picture yourself receiving life-saving radiation therapy, when the clock strikes midnight ...

FootballMuse• 14 years ago

Should I get more sleep, or should I wake up earlier? decisions decisions....

pooriaazimi• 14 years ago

A hackerish question: how can you take advantage of it? Say, in stocks or online transactions?

(I haven't got time to read the article right now (but will do in a week when I'm less busy) and have little to zero experience with times, so forgive me if it's something that's been discussed in the article. I'm just curious.)

rmc3• 14 years ago

Almost certainly not. Remember this happens about every 1½ years, so this has happened a few times recently. I cannot see how you could take advantage of it, since it's the sort of edge case that you'd presume the designers of stock markets would know about.

TazeTSchnitzel2• 14 years ago

SSL certs or something, maybe?

vlisivka3• 14 years ago

SSL certs issued at :60 may have problem with validation. Just reissue them.

mck-• 14 years ago

Time is relative.

ChuckMcM• 14 years ago

I think it would be an interesting PR campaign to ask people what they would do with 1 more second. if time is money, how much money do we inject when we add a second to the year?

Of course we wouldn't have this problem if we just counted seconds from some particular point in space time moving forward. Who cares if the Sun is exactly overhead at noon anyway :-)

capkutay• 14 years ago

How often does something like this (days that last longer/shorter than 24 hours) happen?

sneak• 14 years ago

They are always longer. The Earth's rotation is slowing.

tankenmate• 14 years ago

Umm, actually no. On average the rotation is slowing, but sometimes there are local speed ups.

3pt14159• 14 years ago

Guys do the right thing. If your app is very sensitive to bad data (say financial) just throw up a temporary "down for quick maintenance" page for a couple of seconds and you are good to go.

btipling• 14 years ago

Downtime affects SLAs and there isn't a lot of breathing room depending on your 9's[1]. In addition, bringing something down has its own problems and are you just advocating bringing down the user interface or should everything get shut down, like the entire stack? All the services, queues, databases, block storage, etc?

[1] http://en.wikipedia.org/wiki/High_availability#Percentage_ca...

vr000m• 14 years ago

The document: http://transition.fcc.gov/ib/sand/irb/weritacrnc/archives/nc... tells implementers how to handle events around the leap second. There is some discussion in the ITU-T to all together remove the leap second (but that decision will be taken only before the next leap second).

DrewChambersDC• 14 years ago

I'm as big an astronomy geek as anyone else, but this is so pointless. Why bother wasting time and effort with this? Just let the discrepancies accumulate and adjust 6 seconds every 10 years or so. It would save everyone a little bit of effort, and you could make an event out of it.

Angostura• 14 years ago

If it only happens every 10 years, software developers are likely to forget about it. Hello a batch of crashing systems every 10 years. When it happens every 1.5 years there's a trickle effect - only systems introduced in the last 1.5 years will have trouble and developers are more likely to remember to factor it in.

michaelochurch• 14 years ago

I can't see the point of having leap seconds, and here's why: we already tolerate so much (intrinsic) inexactness in the relationship between solar noon and clock noon (ignoring daylight saving time, which I actually like even knowing that it's somewhat ridiculous) that it seems silly. First, there's the equation of time: solar noon isn't the same clock time every day anyway: it varies by +/- about 15 minutes during the course of the year. Second, we live in time zones set for arbitrary reasons. For example, the average solar noon in New York is 11:55, not noon.

I could understand inserting leap seconds if there were some specific need to have 0 longitude be at solar noon at exactly 12:00:00, but as far as I can tell there's not. If the clock drifts off solar noon by a half-second per year or so, then maybe in a few millennia London will decide to use UTC-1. I could be wrong about this, but I don't see this as a big deal.

IsTom2• 14 years ago

Astronomers and physicists care a lot about this and they are the people running the clocks.

philf• 14 years ago

What's the point of this adjustment? Currently there is an offset of -34 seconds between TAI and UTC and aftwards it will be -35. Seems pretty random to me...

bporter• 14 years ago

I plan on using the extra second to read more Hacker News blog posts!

June 30th 2012 will be 1 second longer: 23:59:60

Related Stories