An Introduction to Unix Time and the Year 2038 Problem

Have you ever wondered how computers keep time? How can computers know what date and time it is by looking at just a single number? What exactly will happen in the year 2038, and why is it going to happen? And finally, how does the future of Unix time look like? If you want to have these questions answered, look no further! This blog will explain to you what Unix time is, how it is stored inside a computer, what exactly is wrong with the year 2038, and what the future of Unix time probably looks like. Without further ado, let's get started!

Unix time is a timekeeping system that is widely used by computers as well as web servers. It was designed to standardize the timekeeping method used in computers. Unix time is defined as the number of seconds since the "Epoch", which is arbitrarily set to midnight UTC, January 1, 1970. The number also excludes any leap seconds that have been added since the "Epoch". For example, in Unix time, "June 1, 1970 at 00:00:00 UTC" would be represented as "13,046,400", since 13,046,400 seconds (151 days) had already passed since the Epoch.

The reason why you can see human-readable dates and times on computers is that the computer uses an internal algorithm to convert the Unix timestamp into numbers/words representing the year, month, day, hour, minute, and second.

To understand why the year 2038 problem is a thing, you must first understand how an integer is stored inside a computer. Unix timestamps are usually stored in computers as signed 32-bit integers (a "bit" is a binary digit, which can be either 0 or 1). One of these 32 bits is used as an indicator for the sign (positive/negative) of the number, and the rest are used to store the actual number. When using 31 bits to store an integer, the largest representable number is 2³¹ − 1, or 2,147,483,647. This number as a Unix timestamp corresponds to 2,147,483,647 seconds since the Epoch, which translates to January 19, 2038 at 03:14:07 UTC. If this number was to be incremented (go up by one), it would cause integer overflow, meaning the 31 bits would not be enough for storing the integer (in this case the timestamp) anymore. And that could lead to devastating consequences, considering how widely computers are used nowadays.

The fix is simple - just switch to 64-bit integers instead of 32-bit ones! In fact, this has already been done in many computers and devices around the world. Technically though, it will still overflow eventually, but that's going to take a very, very long time, so long that it is well beyond the lifespan of the Earth: the Sun will die in 5 billion years, while it will take over 200 billion years for a 64-bit Unix timestamp to overflow!

Sadly, yes. A few years from now the year 2038 problem may not be a thing anymore, but there's still going to be issues in the far future. Thanks to the Earth's slowing rotation, we will have to insert more and more leap seconds into our clocks if we don't wish to change the length of a second. Unix timestamps, however, are not incremented and remain unchanged during a leap second, which would result in more and more ambiguities and other leap second related problems occurring, some of which have already been felt. But those issues are beyond the topic of this blog.

Thanks for reading, and if you are worrying about the year 2038 problem, don't, since it's a widely discussed issue in the field of computer science and many people are now working to address it!