A couple years ago we had issues caused by a 0 (zero) leap second, which honestly I couldn’t find documented anywhere but hacker news! Something about the system expects a leap second every 17 years and if it doesn’t get one it’s more troublesome than the 0 leap second.

https://news.ycombinator.com/item?id=27944776

One of the more unseen side-effects of this particular bug back in 2012 was datacenter internal temperatures spiking by ~5℃ due to the increased CPU usage iirc.

We've already discussed the Leap Smear, where clocks run 0.0012% slower for a day.

https://news.ycombinator.com/item?id=28047714

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

I recall this hitting our startup’s various MySQL Linux servers in 2012.

They were slow/maxed out for a while till we figured it out. The DBA rebooted a few but didn’t know why and it kept cropping up on others; I drilled into root cause with some google-fu.

Not mentioned in the article is that I think this issue occurred again in 2015. I don’t recall if it hit us because we hadn’t patched/upgraded some servers since 2012 (!) and had just relied on resetting the clock/rebooting, or there were more Linux bugs (see LWN below).

Good technical writeup from Linux weekly news: https://lwn.net/Articles/504744/

And more on Linux patching in 2015: https://lwn.net/Articles/648313/

IANA canonical list of leap seconds: https://data.iana.org/time-zones/tzdb-2018a/leap-seconds.lis...

> Hany explains: “Due to physics, at certain times of the year, the Earth moves faster along its orbit than others. How do we base time off of this, then?”

Sorry, but no. This is so wrong I don't know where to start.

TLDR: a leap second overloaded computer systems due to issues in how Linux handles time.