Trifork Blog

A wrinkle in time

June 30th, 2015 by
|

Leap second

I clearly remember the morning of Sunday July 1, 2012, almost three years ago. I was at church, actually, when I got a call from one of our clients: “The website doesn’t seem to be working.” All I could check at that point was that, indeed, the website was not responding. So I called our sysadmin, who found that even SSH-ing into the machine running the site was taking much longer than usual. Finally, restarting everything solved the problem, but we were still unsure about what had happened.

As we found out later, it was related to the leap second, a phenomenon I had not even heard of until then.

The leap second

The definition of our day – 24 hours of 60 minutes of 60 seconds – is supposed to match a single full rotation of the earth. As it turns out, our timekeeping is a bit to rigid for our swiftly tilting planet. It’s actually slowing down. So every now and then, we need to account for the difference between our timekeeping and reality, or in a couple of thousand years, we’d have sunrise at noon and sunset at midnight. This is what the leap second does.

So in the night from June 30, 2012 to July 1, 2012 at midnight UTC, an extra second was added. That’s right: 23:59:60. And it will happen again tonight.

What went wrong last time

As it turned out, our client’s website wasn’t the only one affected. In fact, companies like Reddit and LinkedIn suffered from the same issues. The details are described fairly well in this article. In our case, just like Reddit’s, it was an unfortunate mix of a bug in the Linux kernel, our use of the Network Time Protocol, and Java. Basically the kernel adjusted for the leap second but due to the combination with NTP this caused the Java processes to start spinning and using up all of the CPU.

June 30, 2015 23:59:60

Tonight we will get another leap second. For you folks in the US it will be on the evening of the 30th. For us in Europe, in the early hours of July 1. If your systems start acting strange around that time, suspect the leap second!

Try it out

The Joda date library explicitly doesn’t support leap seconds (you will get an exception if you try to instantiate a DateTime with 60 for the “seconds” value). The Java java.util.Date API documentation seems to indicate it does, but if you try it, it doesn’t seem to. For example, the year 1995 had an extra second on December 31, but Java ignores it:

DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
df.setTimeZone(TimeZone.getTimeZone("UTC"));
Date beforeLeap = new Date(820454399000L); // 31-12-1995 23:59:59 Z
System.out.println(df.format(beforeLeap));
Date leap = new Date(820454400000L);
System.out.println(df.format(leap));
Date afterLeap = new Date(820454401000L);
System.out.println(df.format(afterLeap));

Output:

1995-12-31 23:59:59
1996-01-01 00:00:00
1996-01-01 00:00:01

 

Does your programming language of choice support the leap second? Leave a comment with some code that demonstrates it!

Links

2 Responses

  1. June 30, 2015 at 09:05 by Linas Zvirblis

    Oh man, I just realized that leap seconds occur way more often than one would expect. Funny how there is no standard way of dealing with them.

  2. December 21, 2015 at 14:51 by Casper

    Rather than the somewhat dangerous assertion that all application-level software can handle a 60th second, I prefer the way Google strethes time over 24h to account for an extra physical second, WITHOUT the painpoints introducered by a 60th logical second. This should be the norm in my opinion regardless what the NTP server states.