Date time types have long since been based on a 64 bit number , at least in Linux. However the old 32 bit date time types are still there so older programs won’t break, and probably on emdpbedded systems.p. So it comes down to the apps: how many old apps or old embedded systems will still be around?
It will be interesting to see that play out. The thing is the 238 prboem spas long been solved just like the y2k problem was.
The Linux datetime types were moved to 64 bit values long ago, so this problem is thousands of years out. The old 32 bit values was a limitation of older systems not handling larger values, but almost all hardware today is either 64 bit or has hardware support for 64 bit data. You mainly have some older embedded systems
But the legacy 32 bit APIs are still there so it doesn’t break backward compatibility. You have huge ecosystems of software that still use these APIs and may still handle datelines as 32bit. There’s no way to find them all, much less make sure they’ve been updated.
Just like y2k, 2038 will have been a long solved issue, that may still exist due to ancient or poorly written applications. All you can do is a huge effort of trying everything to find any remaining issues before they cause problems. I’m optimistic because y2k was a problem cased by every application handling their own dates, whereas for 2038 its cause was in an underlying data type that has long since been fixed. Surely all applications will have been rebuilt to the new API in that 20 year or so period, right? Right?
Cant wait till 2038!
Date time types have long since been based on a 64 bit number , at least in Linux. However the old 32 bit date time types are still there so older programs won’t break, and probably on emdpbedded systems.p. So it comes down to the apps: how many old apps or old embedded systems will still be around?
How many cobol systems are still around in 2025. If it works, don’t fix it. And I have a feeling a lot of things will need fixing in 2038 lol
It will be interesting to see that play out. The thing is the 238 prboem spas long been solved just like the y2k problem was.
The Linux datetime types were moved to 64 bit values long ago, so this problem is thousands of years out. The old 32 bit values was a limitation of older systems not handling larger values, but almost all hardware today is either 64 bit or has hardware support for 64 bit data. You mainly have some older embedded systems
But the legacy 32 bit APIs are still there so it doesn’t break backward compatibility. You have huge ecosystems of software that still use these APIs and may still handle datelines as 32bit. There’s no way to find them all, much less make sure they’ve been updated.
Just like y2k, 2038 will have been a long solved issue, that may still exist due to ancient or poorly written applications. All you can do is a huge effort of trying everything to find any remaining issues before they cause problems. I’m optimistic because y2k was a problem cased by every application handling their own dates, whereas for 2038 its cause was in an underlying data type that has long since been fixed. Surely all applications will have been rebuilt to the new API in that 20 year or so period, right? Right?
I expect governments to set up own time servers and reset it to 1970 before upgrading their old Win XP machines.