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.
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.
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).
> 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.
> As you can see, UTC is not a proper, continuous time stream. It has breaks in it wherever leap seconds have been added
I can not see that. 23:59:58 - 23:59:59 - 23:59:60 - 00:00:00 is perfectly continuous, proper, and even monotonic, or at least as much as 23:59:58 - 23:59:59 - 00:00:00 is.
> When you receive a package with a computer-generated time stamp, it is showing this fudged UTC number, not the actual number of seconds according to the atomic stream.
I think you are mixing up UNIX timestamps (which are their own thing) and UTC. UTC and TAI both indicate exactly same thing, there is perfect 1:1 mapping between UTC timestamps and TAI timestamps (ignoring pre-1972 era).
https://news.ycombinator.com/item?id=27944776