Leap second is an extra second occasionally added to Coordinated Universal Time to reflect the changing speed of rotation of the Earth. The most recent one happened on June 30, 2012 at 23:59:60 UTC and the next one, scheduled on June 30 at 23:59:60 UTC is quickly approaching. In this article I would like to quickly elaborate on how this extra second can affect your running production systems and how to design software to avoid any problems.
From the perspective of operations, the most important thing is to make sure that your operating system is up to date. Last time around, a bug in the Linux kernel caused 100 % CPU utilization problems on affected machines or other problems. These issues are now fixed, but can be still present if you are running old OS releases. So, checking if the kernel is patched properly in your OS distribution is definitely a good idea. If you use Red Hat Enterprise Linux, see Resolve Leap Second Issues in Red Hat Enterprise Linux which is the entry point for the mentioned problem. It provides information how to check and test your system. Other vendors might have similar knowledge base articles that can assist you. Note that Windows and OS X machines should be just fine. Usually, NTP or other time synchronization system will ensure that the clock is synchronized after leap second occurs and there is nothing more to it.
As far as other software systems are concerned (runtime, databases), usually some official statement has been issued in relation to this topic. For instance, you can read statement from Joyent about Node.js or statement about MongoDB. The information you will find will often state that the leap second will not affect the running application, but due to the unpredictability, the software usually ignores leap seconds and therefore time operations, such as counting time difference, are not precise. So if precise time counting is critical to your application, you will have to work around this limitation yourself.
Time reporting is another issue that you should look into. Operating systems or other software systems could report the extra second in several ways:
- as :01 on unsynchronized system (that would mean that the system is “in the future”)
- as :59, reporting the same time twice
- as :60 to indicate leap second specifically
- skipping :59 in case the leap second is not added, but removed
This of course can cause several problems. Will your program accept 60 as the correct value? Will it accept request from a system that is “in the future”? Depending on how important it is for you to process such data, you can decide to go the extra mile and prepare your software for it, or decide to leave things as they are, potentially losing some data along the way or creating inconsistency in them.
It is also worth checking date and time functions in the computer language and runtime you use, as some of them might be better or worse suited for your needs. See Data.parse as an example of function that can’t correctly parse the time with indicated leap second.