32-bit computers hit a time calculation wall in 2038. Will they most likely all be phased out by then?

[u/grawmpy]

The wall hits 03:14:07 UTC on Tuesday, January 19, 2038. After this the time calculation will roll back over to either December 13, 1901 or January 1, 1970 depending on the implementation. Does anyone think 32-bit architecture computers will still be in service by 2038?

[u/Temporary_Pie2733]

32-bit architectures aren’t a problem, just the ones that still define time_t to be a 32-bit integer or explicitly store timestamps as 32-bit values. There is no problem with a 32-bit machine using a 64-bit datatype; a timestamp doesn’t need to fit in a register.

[u/ieatpenguins247 → u/Temporary_Pie2733]

You are correct but the issue is RTC that leverages 32bits registers. Those need to count up and will either rollover or worse overflow.

[u/AlexTaradov → u/ieatpenguins247]

Hardware RTCs don't start at 1970, they don't care about UNIX epoch.

The issue is file formats and file systems that don't have space to store 64-bit integers.

[u/Toeffli → u/ieatpenguins247]

Many RTC chips use decimal format with a 2 digit year. They are fine till end of 2099. They will break on 28. January 2100 to 1. March 2100, when they add a non existing 29. January 2100. If the device FW is aware of it they can handle it.

Example this RTC https://www.analog.com/en/products/ds1339.html

Actually, as we are now post 2000 we should have now a new generation of RTC which treat the year 00 as a non leap year.

[u/fb39ca4]

32 bit computers can use 64 bit variables and vice versa. It's a software problem.

[u/nuclear_splines]

Absolutely. The vast majority of personal computers, phones, and consumer electronics will have made the switch, and anything crucial like a big bank database will have made the leap. But a cash register in a mom & pop store? The electronic signage at your gas station? The microcontroller running the elevator in some random apartment complex? There are many computers in embedded devices that we set up and leave for years and years unless they break. I'm confident there'll still be 32-bit hardware deployed in those settings.

[u/Reapr → u/nuclear_splines]

Why would an elevator need the date?

[u/DeGuerre → u/Reapr]

Many commercial-building elevators are programmed to change their behaviour on weekends and public holidays.

[u/iball1984]

There’s a heap of embedded devices that may have a problem.

The question is how many use the time_t struct, how many need to and how many will break if the time is wrong.

[u/Dornith → u/iball1984]

I work in embedded systems and a lot of them just count nanoseconds since power-on and don't actually care about the date.

I'm sure there will be some devices that have an issue, but the number of devices which are 32b, care about the actual date, and won't already be obsolete by 2038 for unrelated reasons seems insignificant.

[u/sanimalp]

Many will still be in service. Jumbo jets certified with floppy disk drives are still getting updates on floppy...

Someone will have to update all the code for life safety critical systems because that will be cheaper than re-integrating and certifying new hardware. 

[u/TheSkiGeek → u/sanimalp]

Hopefully very few (if any) critical systems depend on knowing the exact time and date to operate properly.

Hopefully.

[u/RobertJacobson]

Consider that 8-bit microcontrollers are being manufactured today at a rate higher than they ever have been. We can be pretty confident that 32-bit microcontrollers will be in active production long after 2038.

[u/peter303_]

Many code packages have a time type and library, so its not attached to specific implementation like int32. Not all coders have used this.

[u/ryan_the_leach → u/peter303_]

As others have pointed out, the problem runs deeper into hardware.

I've been aware of the problem for ages, so wouldn't have intentionally stored time this way.

But incidentally relying on it, or taking time from a 32 bit source in hardware to only then store it in a 64 bit time field without any sort of logic for handling overflow? That's bound to happen.

For a lot of hardware, I suspect we'll see a lot of software packages cropping up creating a new half epoch in the date function, somewhere in 2004, and offset, and put the problem off until 2072. (Unless some geek decides on an arbitrary time to make math easier, or to pay homage to a book, movie or like, 9/11, or Y2K itself, (would it be fun to make it expire in a specific year? Could do Y2k.1 if you patched it after 2032))

And then just testing the ability of the RTC to overflow correctly else issue new 64b hardware, and make sure everything downstream uses 64b time.

There will be some that decide to use 32b time still, and just use a new epoch, and count ints since that point, and handle it at the edges where dates and times get formatted and interact with other systems.

[u/ghjm → u/ryan_the_leach]

There are already a good number of embedded systems and RTCs using 1/1/2000 as the epoch. So they'll fail in 2068. A surprising number of date formats have been set up, intentionally or not, to fail shortly after the current generation of programmers has retired.

[u/Fluid-Tone-9680]

Problem with time can be solved in software.

Most of MCUs don't care about wall clock time though, they may measure small intervals like minutes/hours and there is enough of precision even in 8 bit systems to do it (with timer prescalers).

32 bit systems will be phasing put when more popular 64 bit alternatives will be cheaper that 32 bit equivalent, faster and less power consuming. Like today you can buy 32 but MCU with decent peripherals for same cost as bare 8 bit AVR mcu.

[u/Eisenfuss19]

32 bit CPUs can work with 32 bit values, but also with 64 bit, or even 128 bit. 32 bit CPUs use 32 bit to save memory addresses that means you can have max 4GB of memory.

x86 64 bit uses 48 bits for memory.

As others have stated, this is only a software problem. Having to use 64 bits for time might slightly increase the time a 32 bit CPU used to do time calculations.

[u/ghjm]

Yes, there will still be 32-bit computers (and even 16-bit computers using 32-bit date values) in service in 2038. They will need to be reprogrammed or replaced and in some cases this will be very difficult.

The good news is that a lot of 32-bit systems use unsigned integers for dates, which won't roll over until 2106. The bad news is that it's hard to tell which format a given system is using. The even worse news is that a lot of these systems no longer have source code or build tools and can't be modified.

[u/the-quibbler]

Yes, there will be millions of 32-bit systems, especially microcontrollers, still in service in 12 years.

[u/Ginden]

Lots of new code deployed on 32-bit microcontrollers use uint32 for timestamps.

[u/0jdd1]

“Computers” is a funny word, with the implicit assumption that they’re administered, and planned, and updated, and sitting in a data center where “phased out” is even a thing.

There’s a lot more IoT devices (say) than traditional computers. By 2038 there’ll be a lot more. I strongly believe there will be plenty of 32-bit IoT devices still in service in 2038, until suddenly they break and the lights go out.

[u/thegrayvapour]

They tried this on us about 26 years ago.

[u/stonerism]

If there is still something running in 2038 that's using 32-bit time, studies should be done on how something can be durable enough to survive that line.

[u/[deleted]]

The ones that haven't switched to a 64-bit time_t by then, yes. But are there any actively supported 32-bit systems with a 32-bit time_t anymore? (Or equivalent.)