

Why this year's leap second crashed more systems? - laacz

According to Wikipedia (http://en.wikipedia.org/wiki/File:Leapsecond.ut1-utc.svg) , this is not the first year leap second is being inserted. Why so many systems crashed now, but not in, say, 2009?
======
Piskvorrr
(And a corollary: why so many systems are so woefully unprepared for such
quirks in the calendar system, even though such quirks are well documented and
anticipated - albeit not always _regular_? I mean, even _leap years_ manage to
knock down servers, even though they happen regularly, approximately every
four years...)

~~~
nicktelford
I'd surmise that the main reason leap years continue to break systems is that
new software is developed within the time between leap years that fail to
account for them.

Date/time handling is notoriously difficult to get right, and leap years are
an edge case that's triggered very rarely, so it's easy for novice developers
to fail to handle it.

~~~
Piskvorrr
In other words, All Software Sucks. (I mean, shouldn't I already have come to
terms with that?)

------
nicktelford
From what I've heard the majority of the problems we saw this time around were
caused by a deadlock in NTP in a number of Linux kernels (2.6.21 until 3.3 I
_think_ , although that might be wrong).

[source: [http://www.mail-archive.com/git-commits-
head@vger.kernel.org...](http://www.mail-archive.com/git-commits-
head@vger.kernel.org/msg15039.html)]

I know that CentOS/RHEL 6 was affected, but CentOS/RHEL 5.5 (kernel 2.6.18)
was not.

So I guess it's just a coincidence, a bug was introduced in a code path that's
rarely executed and so lay dormant for some time, gaining more and more
victims as time went by and people adopted kernels containing said bug.

