Leap second on June 30 is no Y2K bug, says expert
June 30 will last 1 second longer than an ordinary day, posing a challenge for computer programmers
Most days last for 86,400 seconds, but June 30, 2015, will last for 86,401.
Because the Earth doesn't rotate at a constant speed, scientists have taken to adding the occasional leap second to keep international timekeeping in line with the world's super-accurate atomic clocks.
The last leap second, added on June 30, 2012, caused trouble for some organizations. Flight reservation systems failed at Australia's Qantas Airlines, causing flight delays. Reddit, the popular online message board, was knocked offline after its Linux-based servers failed to cope with the leap second. Other websites were similarly affected.
When the upcoming leap second was announced in January, some media organizations were quick to forecast a crisis: "This Year's Y2K: 'Leap Second' Threatens to Break the Internet," screamed the headline of one article that warned readers to "Get your apocalypse bunker ready."
The apocalypse seems unlikely on June 30. But getting computers to add an extra second in a day is a complex challenge indeed.
How to add a leap second
A second of time is insignificant to most people, but accurate timekeeping is critical for networked computers to communicate properly. A computer scientist named David L. Mills started working on the problem of networked time in 1981, and created what became known as the network time protocol, which has since become a foundation of the internet.
Network time protocol is designed to synchronize computer clocks with co-ordinated universal time (UTC), the internationally agreed upon successor to Greenwich mean time. Because UTC accounts for leap seconds, network time protocol must do so as well.
The protocol accomplishes this feat by giving computers a way to count that rare "extra" second. In the second after 23:59:59 on June 30, computer clocks synchronized via network time protocol won't roll over to 00:00:00. Instead, they'll go to 23:59:60, a special, 61st second in the minute just before midnight.
Smearing a second
Other programmers take a different approach. Google, which runs an enormous synchronized computer network, has developed its own solution called a "leap smear." Rather than adding a second, Google programs its internal time servers to "lie" about the time over a 20-hour window around the leap second. By adding a minuscule amount of time to each second counted by its server's clocks during the window, Google gains the necessary one second over time. Amazon Web Services uses a similar method to add leap seconds.
The primary problem with Google's approach, says Stenn, is that Google's clocks will be slightly out of sync with the legal definition of time during the 20-hour smear window. Halfway through the window, Google's server clocks will be half a second off from UTC.
"One of the problems is that [network time protocol] works by assuming that everybody else out there is playing by the same rules," says Stenn. By playing under different rules, Google and other companies using the smear approach will be creating a temporary discrepancy in networked time.
"What solves the problem for one person may create a problem for somebody else," says Stenn.
Not quite Y2K
The computer problems caused by the 2012 leap second can ultimately be blamed on unprepared programmers and system administrators, says Stenn. This time around, they might be more ready for the challenge.
"I know guys who are all ready for this, because they've known this was coming, they've built their test labs … they test all their systems by getting an isolated set of machines" and simulating a leap second, says Stenn. "These guys will have absolutely no trouble."
Other, less-prepared computer server administrators may suffer problems after the leap second, says Stenn, but individual computer users probably won't notice any issues.
"This isn't really like Y2K," says Stenn. "Y2K was a giant non-event mostly because so much work went into fixing everything that there weren't any problems."
Stenn's been putting in the time to make sure that June 30 will be a non-event, too. He says he's been working on network time protocol for 16 to 18 hours a day since the beginning of June, to ensure that the last second of the month passes without incident.