Leap Seconds Are Gone 🦀

I just learned that leap seconds will finally be abolished* by 2036! I think it's great news for programmers. But wait, what are leap seconds?

What are leap seconds?

Everyone knows about leap years. Every 4 years (with some exceptions), one day is added to February and it becomes 29 days long. But not many people know about leap seconds. Indeed, sometimes a day will end at 23:60 rather than 23:59!

The reasoning is similar to leap years - since Earth's rotation speed isn't constant, deviations are bound to occur every now and then. To account for them, in 1972 a committee was established to watch over Earth rotation and add leap seconds if the clock is over 0.5s off. Since the leap seconds can't be predicted in advance, they come on a short notice - the committee typically issues a statement about half a year before the scheduled leap second. By the way, leap seconds have only ever been added on June 30th and December 31st.

This might seem like a decent idea. But since the leap seconds are so unpredictable, accounting for them requires a joint work between scientists, governments and programmers. Let's ignore the two former groups as ones of little interest to us, and focus on the programming side.

Many programmers expect .second fields of whatever datetime library they use to return a value in the range of [0, 59]. But because of leap seconds, it's actually [0, 60]. Some programs may feature custom datetime difference algorithms, calculating the difference in days and multiplying it by 24*60*60. But some days have 24*60*60+1 seconds!

Unsurprisingly, the fact many programmers don't know about leap seconds (despite them being older than most programmers) causes plenty of bugs. Some of them even happened in software seemingly made with leap seconds in mind.

Unfortunately, due to how rare leap seconds are, leap second-related code often isn't battle tested, leading to many of similar uncaught issues. While nowadays most big software seems to have taken care of it, we are about to face an entirely different issue...

Earth Rotation

Remember how earth rotation isn't constant? Due to it being a tiny bit slower than one rotation every 24 hours, leap seconds were added. But there is a problem - Earth speed is increasing! In fact, there hasn't been a leap second since 2017 (in comparison, from 1972 to 1998 there's been 22 leap seconds - 0.8(148) leap seconds a year). So, what's next? It's assumed that a negative leap second will happen around 2029.

Well, this is a problem. We are relatively well equipped to deal with added seconds. But seconds were never removed from days (actully they were, more on that later). This means that as of now, we are completely unprepared for the challenges of the new reality, with Earth spinning 0.0000003% faster than one rotation a day!

If you believe in our ability to cooperate to solve complex tasks together, maybe you'll say - let's just add the code for dealing with negative leap seconds by 2029, how hard could it be?

Well, really hard. First, many time-related programs run not on servers, not on smartphones, not on desktop computers, not on IBM mainframes, but on satellites, which can be hard to update. Second, there's a lot of outdated software out there that doesn't receive patches (but is still used by people because, well, it works...). Third, many of such software doesn't even have source code released, so it's impractical to patch it.

In short, we're fucked.

Luckily, the 27th General Conference on Weights and Measures held in November 2022 decided to abolish leap seconds by 2035! Finally, no more leap second bugs?

However, leap seconds solve an issue which still has to be solved even without them - which is, astronomical time getting out of sync with UTC. What is the solution? Well, look... they decided to batch leap seconds, so there will be a "leap minute" or similar!... And depending on Earth rotation, it might be a negative leap minute!

...Yeah, we are so not ready for this. Here's hoping humanity will learn to cooperate better by the time this becomes a problem.

Appendix: time bugs

Y2K is perhaps the most well-known instance of time-related bugs, although it wasn't very widespread due to everyone having prepared for it in advance (and I'd assume in large part due to the fact computers don't use decimal system, so 99 won't overflow).

A much more serious issue is related to Unix timestamps. They are calculated by counting the seconds from 1970-01-01 (leap seconds are supposed to be ignored, so 23:60 has the same timestamp as 24:00, but I'd assume there's many software that doesn't ignore them). If you store a Unix timestamp (which is a common way to store time) in a 32-bit signed integer, the max timestamp you can store is 2038-01-19T03:14:07. This is known as Y2K38. If you store it as an unsigned integer, the problem will instead occur on 2106-02-07T06:28:15, which is... slightly better?

After overflowing, the integer will become negative (rather than zero), and since Unix timestamps are expected to be strictly positive, the range of bugs can vary greatly. In fact, we already saw some related bugs when a software was adding 20 years to the current date (although I don't remember what software it was so I can't link to it).

The solution is simple - to switch to storing the timestamps in a 64-bit integer. In fact, there's so many bits you can store milliseconds rather than seconds and still have much more leeway (it will be enough for 584541993 years from now). Of course, it's very hard to switch to it for all software for reasons outlined above (see: why it's hard to implement negative leap seconds). That's why we are bound to face some issues in 2038... mark it in your calendar!

On a totally different note, there's a system called GPS week number rollover, which resets the GPS week number every 1024 weeks. The first rollover happened in 1999, and was relatively uneventful because GPS wasn't widely used among civilians back then. The second rollover happened in 2019 and uncovered many more issues. The third one will, coincidentally, happen in 2038 - just in case one time-related issue wasn't enough for the year.

Let's look at what issues the 2019 rollover caused. A relatively widely-known bug was found in gpsd in 2021 (gpsd is a Linux daemon to receive GPS transmissions used by many time sync servers). There was code to predict what 1024 week range it is currently based on expected leap second offset, and if it seems that there's fewer leap seconds than expected then time is rolled back by 1024 weeks. Predicting how many leap seconds there will be N years into the future - what could possibly go wrong? Just if that wasn't enough, the dev made a calculation error, and set the check year to 2021 rather than 2022, so the leap second number was even more off by the check time. Quite predictably, there wasn't enough leap seconds by the check time in October 2021, and it would've reset the time to 2002. The issue got patched quickly after discovery, but who knows how many servers were left unpatched by then (given the bug was patched in August).

Moral of the story: don't try to predict leap seconds.

Among other issues, many phones sold before 2013, including unupdated iPhones, couldn't properly sync time with GPS anymore after 2019. But those issues are boring, so let's ignore them.

Since time is managed by humans and has a long history, there are other weird properties it has. For example, it isn't always continuous - it can repeat (when it's rolled back by the government, or during a DST shift), or it can be skipped (again, due to government interference or a DST shift). This is one of the major reasons for introducing UTC. On the link above, it's explained that in Shanghai, 1927-12-31T23:54:08 happened twice because clocks were rolled back at the end of 1927. Since those periods depend on the timezone, a timezone DB is more than just "for each timezone, specify UTC offset and whether it has DST", it's also information about historical changes in that timezone.

This doesn't matter if you use UTC - but many programs don't have that option and force you to use local time! Worse yet, often the timezone isn't specified, and you have to guess whether it's UTC or some kind of local time.

In conclusion, time is an extremely tricky subject. Even if you are supposedly handling it perfectly, weird issues can crop up. Some edge cases are so rare that you only learn about them when they happen.

We can only imagine what new "exciting" issues we will face when colonizing new planets. Regardless, remember to rigorously test your time-related code, and use UTC and ISO8601 whenever possible!