It is worrying. A possible work around for the remaining 32-bit systems would be a patch to switch to using an unsigned 32-bit integer for time storage, however this will only work for systems that don't need to deal with dates before 1970, but pushes the problem back to 2106.

You also will have to be absolutely sure that those systems will never run code that compares timestamps using a signed 32-bit comparison. That means vetting all the code, not only the OS.

Even for devices where all the code is in ROM, that can be difficult. Source may be lacking, or there may be binary blobs bought from companies that do not exist anymore.

For embedded systems, PIC24 microcontrollers are still popular. Those are 16 bit microcontrollers typically used without operating system. The one I last wrote production software on will display incorrect dates in 2036, and there are no libraries available to mitigate that.

At least in my case the date weren't mission crucial, but I expect a lot of factory hardware to behave weirdly starting on either 7th February 2036 or 19. January 2038.

Why those two dates?

The 19th January 2038 is 2^31 seconds after the unix epoch, when 32 bit linux timestamps wrap around. On 16-bit PIC microcontrollers the default implementation of the gmtime function wraps already 0x0x7C55817F seconds after the unix epoch (I forgot why, it was probably about efficiency). That works out to 7th February 2036, likely catching a lot of companies off guard (seemingly everyone focuses on 2038). Some systems also use 1980 as the epoch, so maybe we'll see some problems again in 2048.

Calling it just the Year 2038 problem is misleading because lots of platforms and implementations add their own twist, skewing the crucial date by a few years. Linux is a big platform, but there are countless niche alternatives as processor resources get scarce or realtime requirements get tight.

2036-02-07 06:28:16 UTC is 2^32 seconds after 1900-01-01 00:00:00 UTC. Some systems represent time using a 32-bit unsigned integer counting seconds since 1900.

1 JAN 1970 was a judicious choice for the UNIX epoch date; it allowed a 32-bit signed integer time_t type (counting seconds) to handle dates almost all the way back to the year 1900 as well as 'way into the future.

Very likely it's already to late for some systems. I wouldn't be surprised if some of the systems already in production will last until sometime after 2038.

Expecting short upgrade cycles is normal in software/computing, but for manufacturing 30 to 50 years doesn't seem unrealistic. 23 years is a very short time, even if we stay in the field of computing, mainframes are getting close to 23 year life cycles.

Or, worse, actual binary protocols that use 32bit integers to represent time values.