The addition of a leap second to the world's atomic clocks this weekend produced some spectacular crashes of Java software around the web. (One might wonder why not in other software? But that question is complicated enough to require a separate post) Some of the more notable epic fails were in Redit, StumbleUpon, Yelp and FourSquare and other systems running Hadoop and Cassandra possibly in combination with Firefox.
In 2006 we reported a large-change clock vulnerability that affected Zone Alarm, Norton, and several other anti-virus vendors and Microsoft. The security companies quickly remedied the problem but Microsoft hedged until we produced a proof of concept exploit. Software vendors typically don't really care too much about date based issues unless they affect security or credibility.
The leap-second clock problem was a small-change clock issue which probably should have been tested just in the likely event that someone would eventually block the time synch port and duplicate this issue by accident. It is incumbent upon developers of 24x7 software to plan for the unexpected and test their systems for time-change crashes and vulnerabilities. Timing attacks in various forms are often part of a hacker's arsenal and should be part of every test plan.
As authentication systems and date-based database transactions rely more strongly on precise clock synchronization, it is important for the computing community to take clock changes a little more seriously and notify industry ahead of time so these issues can be tested and addressed. Leap-second tweaking will continue in the future as the earth and moon continue to synchronize. Software, just like the earth and moon, has to adjust accordingly.