[nycdotnet]

The 2038 bug is less than 14 years away at this point. There is an astonishingly greater amount of software out there compared with 24 years ago. I don’t want to be a doomsayer but it’s probably time to keep this in mind anytime you implement an epoch going forward.

[nitwit005]

There is a lot more software now, but a big portion of that is in languages that have an internal time representation larger than 32 bits.

As others suggest, I'm expecting a lot of the issues to be embedded code.

[marcosdumay]

Almost all software is 64 bits nowadays, and avoids the problem entirely.

But "almost all" is not "all", and won't be until there. It will certainly be interesting, as stuff will fail in a completely different way from Y2K.

[dsr_]

Right now Debian is in the middle of making sure that all of the 32-bit software has 64-bit time_t. Descendant distributions will benefit from their work.

Are other Linux distributions doing the same thing? Sure, and there was a lot of work in the kernel (mostly in the 5.x series) to get it all nailed down. NetBSD and OpenBSD already tackled it.

But "all" can't be guaranteed, because people insist on keeping elevator controllers and industrial processes and anything which hasn't actually had capacitors explode and resistors melt running for an extra decade.

[wongarsu]

A lot of embedded software is still running on 8 bit microcontrollers. The market has shifted towards 16 and now 32 bits, but 64 bits isn't that common yet. And a lot of the software libraries provided by microcontroller manufacturers are terrible and absolutely affected by Y2k38.

Expect lots of IoT or home security devices to malfunction. Or more critically industrial equipment, fire alarm systems, factory automation, etc. A bit over a decade a ago I helped develop an industrial spark extinguishing system. It's still sold and each setup will probably be used for 20-40 years. I know it will suffer from Y2k38, though probably (hopefully) only the event logging. When I raised concerns over this the answer from my boss was "I will be retired by then, don't spend time on that".

[darkwater]

> When I raised concerns over this the answer from my boss was "I will be retired by then, don't spend time on that".

But...isn't capitalism supposed to fix this kind of reasoning? Turns out that what you really need is people caring for the right thing to do, and not just for money. Yes, often the right thing to do in a business context will lead to more money. But when time-frames expand and you are not the real owner...

[teractiveodular]

The problem is not so much OS-level support, but all the legacy databases etc storing 32-bit timestamps.

[marcosdumay]

Oh, yeah, there are protocols, file formats, old devices, all kinds of interesting things. But more importantly, differently from the last time, they are very different from each other, so much that it's hard to even anticipate what may break.

I imagine a couple of days with the internet misbehaving everywhere is a safe bet.

[mrpippy]

Even talking about software running on servers, I think there’s more 32-bit software than you assume.

But my real worry is embedded systems, where very little is 64-bit. Almost every embedded Linux system, IoT crapware, Android anything. Almost none of it will be able to keep time after 2038.

[dsv3099i]

On the other hand, pretty much anything manufactured after the year 2000 only lasts like 5 years...

[ninkendo]

> Almost all software is 64 bits nowadays, and avoids the problem entirely.

Sure, we say that now, but 584 billion years from now when we use up 64 bits, we’re going to be cursing our ancestors for being so short-sighted.

[imron]

A large amount of embedded software runs on 32bit and can't be readily patched.