The Year 2038 problem is well-known among Unix users.  Unix keeps time by counting the number of seconds since the epoch, which is midnight, January 1, 1970.  As I’m writing this at about 8:30am on July 27, 2025, here is the current epoch time:

# date '+%s'
1753630264
# date
Sun 27 Jul 2025 08:31:05 AM PDT

Naturally, that number increments once a second.  But as we know, data types always have a limit of how big the number they can store.  Traditionally, the epoch second was held in a 32-bit unsigned integer.  Back when Unix was created in the early 70s, 32-bit was state of the art.

But you can see where this is going.  At some point, your Unix or Linux system will hit the maximum number that can be stored in a 32-bit unsigned integer (2³² – 1 = 4,294,967,295), which is precisely 03:14:07 UTC on January 19, 2038.

It’s Y2K all over again, though with a completely different cause.  The Y2K threat was caused by programming conventions at the application layer.  Programmers would store a date as “85” instead of “1985” and when the calendar rolled over to 2000, there were all sorts of problems that could occur, depending on how the application code was written.

Here, the problem is at the system because the system would start reporting that it’s January 1, 1970.

This problem was recognized a long time ago.  The obvious solution is to change time_t (the C library type, which is an unsigned 32-bit int) to a 64-bit unsigned int.  I don’t know what the exact date is when that will rollover, but it’s 584 billion years from 1970, which is over 40 times the age of the universe.

I mean, sure, inevitably there will be someone still using a 64-bit distro from 40,000,000,000 A.D. that is long out of support, but…I think everyone can accept this solution.

Fixing Debian

Debian 13 “Trixie” will be the first version of the world’s greatest Linux distro to have a fix for Y2038 in place.

Now you might think, isn’t this a really easy fix?  You just go into time.h and change time_t to a 64-bit int and recompile, right?  The challenge is all the packages (6,429 in fact) that reference it.  Well, you continue, shouldn’t they just work after recompile?

Many (most?) probably will.  But programmers may also be making all kinds of assumptions about time_t being 32-bit, particularly when they’re adding times.  For example, “I need to add two (32-bit) epochs, so I’ll store the result in a long (64-bit) integer”.  Now what if suddenly you’re adding two 64-bit epochs?

Or what if there is a binary format that allocates 32-bit for a timestamp?

Or…it’s one of those situations where you inevitably need a human to analyze the problem.  For 6,249 packages.  Kudos to the Debian team for doing all this hard work to get Trixie ready.

Puffy Leads the Way

When I first read this, I was surprised because I honestly thought this had been done a long time ago.

Then I realized I was thinking of OpenBSD, not Linux.  OpenBSD made this change way back in version 5.5, which was released in…2014.  And released a cool song about it.

In August of 2012, Philip Guenther started the OpenBSD work to solve this. After a year of work it was ready enough for merging, and in August 2013 the time_t type was changed to int64_t on all platforms and the kernel and userland were adapted to the new situation. The initial work was committed right after OpenBSD 5.4, then polished in tree over the next 6 months.

The next part of the process was to drag the “ports” software ecosystem along because no one else had paved the way for 32-bit machines to run with 64-bit time_t. This required a fair bit of upstream involvement. Thousands of fixes were required to make both 32-bit and 64-bit time work transparently. There will be more fixing in the future, but the concept is proven.

In the past OpenBSD pushed risky theoretical ideas into mainstream software practice by proving the ecosystem was ready to change. No OS wants to make a ABI jump until the case for change is proven. Stack protection, ASLR, and W^X principles are now in common use by mainline operating systems… because things like Firefox and Postgresql don’t break anymore. OpenBSD built that route.

In the same way, the road is paved for the 64-bit time_t transition. Other operating systems can now make this jump.

This highlights the difference in development landscapes between the two sides of the Unix family.

The BSD world (OpenBSD, FreeBSD, NetBSD) have always kept kernel and userland in a single tree.  That means on OpenBSD, you can issue a single “make world” command to build the entire operating system – kernel and everything in /bin, /usr/bin, etc.  That means if you make a change like this, you’re in effect changing a single code tree, not 6,249 packages.

Conversely, on Linux the kernel is just the kernel.  Change something in the C standard library and you have many packages by many maintainers and developers to go change.

Of course, OpenBSD doesn’t keep everything in its tree.  To take one of thousands of packages as an example, OpenBSD doesn’t maintain its own copy of PostgreSQL.  So for packages like that, they still have to work with upstream maintainers to fix code.  But for the base operating system, everything is one tree.

Congrats to Debian for catching up.  But…no song?

raindog308

Raindog308 is a longtime LowEndTalk community administrator, technical writer, and self-described techno polymath. With deep roots in the *nix world, he has a passion for systems both modern and vintage, ranging from Unix, Perl, Python, and Golang to shell scripting and mainframe-era operating systems like MVS. He’s equally comfortable with relational database systems, having spent years working with Oracle, PostgreSQL, and MySQL.

As an avid user of LowEndBox providers, Raindog runs an empire of LEBs, from tiny boxes for VPNs, to mid-sized instances for application hosting, and heavyweight servers for data storage and complex databases. He brings both technical rigor and real-world experience to every piece he writes.

Beyond the command line, Raindog is a lover of German Shepherds, high-quality knives, target shooting, theology, tabletop RPGs, and hiking in deep, quiet forests.

His goal with every article is to help users, from beginners to seasoned sysadmins, get more value, performance, and enjoyment out of their infrastructure.

You can find him daily in the forums at LowEndTalk under the handle @raindog308.