The End of Unix Time: What Will Happen?

Nicholas Obert

How will the date rollback affect computer systems?

Photo by Aron Visuals on Unsplash

Since the dawn of time, people felt the need to keep track of time. From simple notches carved in the rock to astronomical clocks such as Stonehenge, we have always been trying out new and more precise ways of representing the flow of time. Fast forward a few millennia and here we are, carrying around high-precision clocks in each of our electronic devices.

If you are just a bit curious, Chances are you have wondered how your computer or mobile phone handles the flow of time and represents it in a human-readable format.

In order to understand time systems in the field of computing, we have to first talk about the epoch. In chronology, an epoch is an instant in time chosen as the origin of a particular calendar era from which time is measured. For example, most countries have adopted the birth of Jesus Christ as the starting year for their calendar.

Back to computing, Unix-like systems agree to have their epoch on the 1st of January 1970, at 0:00:00 UTC. This date has been chosen arbitrarily as the reference instant from which to count time. Other systems, such as Microsoft Windows, start counting from January 1, 1601, as this was the first year of the Gregorian calendar cycle active when Windows NT was being designed (Microsoft blog).

The Unix time standard measures the number of seconds elapsed since its epoch, although many modern implementations provide higher precision, up to a few nanoseconds.

Representing time

In computer systems, time is usually represented as a number, integer or floating-point, that is constantly incremented with each tick of the computer’s real-time clock (RTC), an electronic device that measures the passage of time.

How time is stored in memory, however, depends on the specific system implementation. Most 32-bit Unix-like systems store time in a 32-bit (4 bytes) signed integer and are thus able to represent a range of 136 years, from 1901 to 2038. Other 32-bit implementations use unsigned integers and can represent years up until 2106, but cannot handle dates before the epoch.

Modern personal use devices run 64-bit operating systems, which keep track of time with a 64-bit signed value and are able to represent dates until approximately 292 billion years from now, which is, by the way, much more than the estimated age of the universe.

The end of time

Sooner or later, the clock will reach the highest time value that can be represented in the system. The most imminent overflow date is the 32-bit signed integer-based systems’, scheduled for 19 January 2038, at 03:14:07 UTC. One second later, computers will fall back to 13 December 1901, at 20:45:52 UTC.

This behavior is due to an integer overflow occurring at the time of adding the next second. Integer overflows happen when an arithmetic operation results in a numeric value outside of the range that can be represented with the given number of digits, in the case of 32-bit signed dates is -2³¹ to 2³¹.

The reason the date rolls back to 1901 is that signed integers use their most significant bit to tell whether they are positive (0) or negative (1). Below you can see a nice visual explanation of how the overflow affects the date. Remember, the leftmost bit represents the sign of the binary number.

Signed integer overflow causes dates to roll back (from Wikipedia)

Unfortunately, this integer overflow won’t just affect the date displayed on your screen, but will also cause many unexpected behaviors. Let’s now explore a few scenarios.

The first issue that comes to mind is the inability to measure time correctly. For example, let’s measure how long it takes to execute a certain operation while the time rolls back:

And the output:

It took -4294967290 seconds to complete the task.
In human-readable terms: -49711 days, 17:31:50

While the function took only six seconds to execute, we get a clearly wrong measurement of -49,711 days. As you can see, this bug can cause a whole lot of problems across many applications.

Sleeping for a negative time delta can make your programs wait indefinitely, causing a never-ending denial of service, as you can see by running this simple C code snippet:

Moreover, a negative timestamp could trick version control systems into thinking a certain file or resource created after the rollback is older than anything created before 2038. This could lead to a variety of bugs, including the inability to update data stores and all kinds of weird synchronization problems.

Despite these catastrophic scenarios, all critical systems will either be replaced with 64-bit architectures, or a workaround will be applied to mitigate the issue for older systems that may not be replaced.

What about 32-bit unmaintained software? Unfortunately, it may not be usable anymore after the rollback, or you could just set the system date back to 1970 and call it a day. Anyway, you should never use unmaintained software in systems that have any importance.

Some concrete problems, though, may arise from embedded 32-bit systems that make use of time, such as electronic home appliances or computers inside old cars. These devices might stop working and you won’t be able to do much about it.

I hope you enjoyed this article.

Thanks for reading!

Leave a Comment