For the 26th time since 1972, the world will observe an extra second at the end of the last minute of the day on the 30th June 2015. For (literally) a brief second, 23:59:60 will exist. And yes, this actually matters to some of us.
Why? It’s called a leap second; a second added to the end of the minute to ensure that UTC remains accurate according to the earth’s rotation. With tiny irregularities in the earth’s rotation, the leap seconds help to ensure that these are taken into account. It’s a small detail, but without leap seconds, we’d be 25 seconds behind where UTC should be, and without correcting, we’d end up 26 seconds in July.
For the majority, the second will pass unnoticed around the world, perhaps only with some geeks capturing screenshots of the moment to post on Wikipedia. But it has software engineers and developers taking a deep breath as they try to assess how their systems will handle the extra second.
As software developers, there are some more considerations to be made. AWS has already got the ball rolling with their Look Before You Leap post explaining how they’re going to handle it. For their EC2 instances, they’re advising instance owners to enable network time (NTP) updates which will ensure clocks that do fall out of sync or handle it badly are then automatically updated shortly after to correct time again.
Where their management console is involved, they’re taking a slightly different approach, adding 1/86400 of a second onto every second in the following 24 hours after the leap second. Whilst at first there was some confusion about why they are handling this in such a complex way, it begins to make sense when you consider how many of their management console systems – scaling and backups, for example – rely on to-the-second accuracy, and how an extra second might just throw things into disarray. Although, it’s probably more a precaution than anything else.
Google have taken a different tack, slowly accounting for the leap seconds before it happens. A standard operation NTP server sends an ‘LI’ flag as a leap second approaches, indicating to all connected machines that they should add the extra second onto the end of the day. Google modified it’s internal NTP servers to ignore the ‘LI’ flag and instead add a couple of milliseconds onto the end of each second throughout the 48 hours prior to the event. They call this technique a “leap smear“, and it makes sure they their super-sensitive distributed systems did not come out of sync, which could cause problems for a company the size of Google.
So what does this mean for Average Joe the Webmaster? Well, actually not very much. In the run up to the leap second, you’re sure to hear nervous forum chit-chat and potentially a few more blog posts from the Fortune 500s explaining how they’re tackling it with innovative techniques and complicated formulas. Perhaps there might even be references to Y2K.
For the most part, it’s about ensuring that the servers will handle the extra second correctly, and ensuring that NTP is enabled. A simple call to
ntpstat in shell should give you the current time synchronisation status, you’re looking for output like
synchronised to NTP server (184.108.40.206) meaning you’re all good to go. For a great run-through of getting NTP setup correctly on a server, check out http://www.thegeekstuff.com/2014/06/linux-ntp-server-client/.
Whilst MySQL should handle the leap second correctly in terms of storage, it transforms leap second values to “23:59:59” so there’s potential that for both consecutive seconds, the time stored for records is “59”. Whilst this helps any SQL queries within your code, there’s potential for some strange behaviour if the server is reporting time as 23:59:60 and MySQL is returning time as 23:59:59.
At the end of the day (no pun intended) there’s not much to be worried about with this leap second. Most of the major players are mitigating any problems from a hosting point of view, and most libraries will handle this fine, but it’s important to review how this might affect other time-dependent parts of your system, perhaps including cron jobs or queued workers, and ensure that they aren’t going to be affected. Well, that’s what were doing at British Software Development anyway.