2038 == 2000

How many of you remember the Y2K problem? How many of you had to fix your way through it? For those that weren't involved, the Y2K bug was the result of an optimization. It went something like this, circa 1970:

Dev 1: Our database is getting too big. We need to save some space.
Dev 2: Ok. Let's not store redundant data.
Dev 3: Hey, Look. All of the years stored in our database start with 19. Let's not store that
Dev 1: Great idea. We've got 1,000,000 users, and 2 bytes per row is 2 MB.
Dev 2: Wow, we'll fit in memory again. Way to go man.

And it was so. And it worked. And for 20 years no-one noticed. Then some tester got fancy and put in a date a few years in the future and something broke. Time seemed to go backward. Things that were supposed to be 2 years away were 96 years ago. Or displays were just wrong and showed as 19XX. But slowly people fixed the problems. Then the internet found out about it. And there was much wailing and gnashing of teeth. Prophecies of doomsday. The power grid was going to fail. The phones would stop working, Turn your computers off before midnight on Dec 31st, 1999 or they would melt.

Of course, as you can tell since you're reading this on a computer, most of those predictions didn't come true. Yes, some displays were wrong, some programs crashed, and others got things wrong, but generally it was a non-event.

So we're safe right? Not exactly. In the Windows world, anything built with VC8+ (2005) is good until the year 30,000+, but if you're still running something older (like an embedded system running Win-CE) you'll probably have issues. And in the Unix world almost everything is time_t based and good until 2038.

Of course 2038 isn't that far away anymore. And our favorite penguin isn't ready. The 5.6 kernel will be ready soon, but that doesn't mean the programs in user space are ready. That's on us to deal with. It could be as simple as a recompile to run on the new kernel, but there's more to future-proofing than just recompiling and deploying. Think about persisted data. What about databases and files with old timestamps in them? Or that nifty new gRPC protobuf you wrote to disk with a 32bit timestamp. We need to think about these things and deal with them before time runs out.