Year 2038 problem

Last Updated on February 19, 2026 by Dave Farquhar

We need to talk about the year 2038 problem. The year 2038 problem exists on Unix and Unix-like systems, and other software that borrowed the Unix time standard. The problem is that on January 19, 2038, the 32 bit integer that Unix uses to represent time is going to wrap around. And then the computer is going to think it is December 13, 1901. If this sounds a lot like the Y2K problem, you’re not wrong. The dates involved are different, but the effect is very similar.

How Unix measures time

This problem exists because Unix measures time by counting the number of seconds that have elapsed since January 1, 1970. Why that date? I always heard that is the approximate birth date of Unix. Whether that means that’s about the day that it booted for the first time or about the date that the first system went into production, I don’t know. I wasn’t around yet. In 1970, it seemed like a reasonable way to measure time and 68 years seemed a safe distance away.

The ticking 2038 clock

January 19, 2038 is 12 years away. That might sound like a lot. I don’t think it sounds like a lot. The reason I say that is because Microsoft releases software on a predictable life cycle that last 10 or 11 years, and yet, I still regularly talk to people who have Windows 7 systems in their environment. Windows 7 is so old that its successor is now discontinued. There was also very little software that runs on Windows 7 that will not run on Windows 10 or Windows 11. And yet, 20 year old systems persist in corporate environments.

Since operating systems have a 10-year life expectancy, my radical idea is to spend 5 years of that migrating to the new operating system. I’m used to hearing I’m nuts.

The year 2038 problem is harder to solve than the Windows upgrade problem. We have a reasonably good inventory of Windows systems on corporate networks. If you don’t have anything else, you at least have Active Directory to fall back on. And we still can’t get it done. You don’t have any such thing with Unix and Unix-like systems. At least not by default. And I can guarantee you have embedded Linux systems in your environment but are not joined to your Active Directory, even if you are the type who connects your Unix and Linux systems to Active Directory when you can.

Without an inventory of systems, at the very least you have the problem of figuring out where to start and knowing when you’re done.

Writing off the Year 2038 problem

It is also tempting to write off the year 2038 problem as not a big deal because in spite of predictions, Y2K didn’t end the world. Y2K ended up not being a big deal, not because it wasn’t a big problem, but because a lot of people my age worked very hard to ensure that it wouldn’t be a problem.

If you go back and watch the movie Office Space, the three protagonists in the movie are working on the Y2K problem when they aren’t being micromanaged by their five bosses and getting RIF’ed because The Bobs decided they were redundant. That movie is a frightening representation of what working in IT during the Y2K era was really like. But the reality was so that at least one round of people who worked on the Y2K problem managed to finish the job before getting RIF’ed. Don’t worry though, there was another RIF sometime after Y2K that got them. One got all of us, myself included.

People like me are going to talk about the year 2038 problem and people will ignore us. But a few people will start working on the problem. It may take security companies starting to flag Year 2038 as a vulnerability, but it’s likely they’ll eventually get to that. And at least we have better means to scan our networks today than we had in 1999.

No single solution to the Year 2038 problem

In some cases, software is going to need to be updated to a version that stores dates as a 64-bit integer rather than 32-bit. Or it may be necessary to move files to a newer filesystem that supports 64-bit dates. In some cases, the operating system itself may need a patch or an upgrade.

Also, here’s something fun. Some of that software that’s going to need to be upgraded runs on Windows. Windows itself doesn’t use the Unix method of measuring time as the number of seconds that have elapsed since January 1, 1970. But some software that runs on Windows does.

It’s going to be messy and thankless work, and with job tenures being much shorter today than they were circa 1999, it’s going to be hard to see it through. But it’s going to be necessary. A large percentage of those critical systems that didn’t fail on January 1, 2000 didn’t fail because they never had the Y2K problem. They had a year 2038 problem. That likely includes a large number of systems in critical infrastructure like utilities.

Dave Farquhar

David Farquhar is a computer security professional, entrepreneur, and author. He has written professionally about computers since 1991, so he was writing about retro computers when they were still new. He has been working in IT professionally since 1994 and has specialized in vulnerability management since 2013. He holds Security+ and CISSP certifications. Today he blogs five times a week, mostly about retro computers and retro gaming covering the time period from 1975 to 2000.