Leap Second Bug Causes Crashes

An anonymous reader writes in with a Wired story about the problems caused by the leap second last night. "Reddit, Mozilla, and possibly many other web outfits experienced brief technical problems on Saturday evening, when software underpinning their online operations choked on the “leap second” that was added to the world’s atomic clocks. On Saturday, at midnight Greenwich Mean Time, as June turned into July, the Earth’s official time keepers held their clocks back by a single second in order to keep them in sync with the planet’s daily rotation, and according to reports from across the web, some of the net’s fundamental software platforms — including the Linux operating system and the Java application platform — were unable to cope with the extra second."

Re:

[Anonymous Coward]

>hick-up.

The hick up watching the servers when the leap second came was you.

Re:Our Red Hat servers had no issues at all

[MightyMartian]

Sorry can't remember the name. It's the one that takes the credit for the work of others.

Windows?

Re:Our Red Hat servers had no issues at all

[drinkypoo]

Sorry can't remember the name. It's the one that takes the credit for the work of others.

You must be talking about SCO, but if you're still running CND you should probably upgrade.

Re:FUD?

[kasperd]

Actually I didn't realize I was affected by this bug until a few minutes ago, when I used strace to see why firefox was using up all the time on one of my cores.

You don't need a leap second in order for that to happen. Firefox does that regularly.

Re:What about Windows and Mac?

[Alrescha]

"And apparently neither did any desktop Linux systems."

There are desktop Linux systems?

(ducks)

A.

Re:Why now?

[Guy Harris]

What we should have is what I've described above, time-zero and a counter. And translations from that to localized date time should be handled by a library.

Which, sadly, POSIX doesn't let you have as "UNIX time" [opengroup.org]:

4.15 Seconds Since the Epoch

A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds ( tm_sec ), minutes ( tm_min ), hours ( tm_hour ), days since January 1 of the year ( tm_yday ), and calendar year minus 1900 ( tm_year )) is related to a time represented as seconds since the Epoch, according to the expression below.

If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec , tm_min , tm_hour , tm_yday , and tm_year are all integer types:

tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - (tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400

The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified.

How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds.

Note:

The last three terms of the expression add in a day for each year that follows a leap year starting with the first leap year since the Epoch. The first term adds a day every 4 years starting in 1973, the second subtracts a day back out every 100 years starting in 2001, and the third adds a day back in every 400 years starting in 2001. The divisions in the formula are integer divisions; that is, the remainder is discarded leaving only the integer quotient.

If there were a UN*X API to get a count of seconds since the Epoch (in addition to, or instead of, a call to get "seconds since the Epoch"), and a UN*X API to convert those to UTC and local time labels, that would get what you want. Modulo making it work with NTP, the former could be implemented with less difficulty than a call to get "seconds since the Epoch", and the latter is called "the Olson code complete with the leap seconds database".

However, that would then require some mechanism to allow code to schedule something to happen at a given UTC label; simply calculating the UNIX time for that UTC label, getting the current UNIX time, and scheduling it for then-now seconds in the future is insufficient, as the UNIX time for a given UTC label in the future might change if a leap second is scheduled between then and now. (Note that if you support scheduling something to happen at a given local civil time label would already require correction of that sort to handle DST rule changes.) This would also have to do something if you schedule an event for YYYY-DD-MM 23:59:59 and a negative leap second occurs so that there is no 23:59:59 on YYYY-DD-MM; "something" might be "let somebody know and ask them to correct it" or "do it at 00:00:00 on the next day", perhaps depending on the reason why it's scheduled.

Re:You probably don't do much Java, then

[thegarbz]

I can even see a small bump in the power-usage around two o' clock (0:00 GMT).

Leap seconds contribute to global warming. We need to raise this at the next G8 summit.