That’s easy. The 2038 problem is fixed by using 64-bit processors running 64-bit applications. Just about everything built in the last 15 years has already got the fix
Using that fix, the problem doesn’t come up again for about 300 billion years
You don’t need 64 bit programs or CPUs to fix the 2038 problem. You just need to use a 64 bit time_t. It will work fine on 32 bit CPUs or even 8 bit microcontrollers.
Linux kernel updated to 64 bit time quite recently. In 2038 I can guarantee somebody in a very serious business is still using an ancient RHEL and will have issues.
hopefully by then it’ll all be sorted by whatever fix they implemented before 2038.
That’s easy. The 2038 problem is fixed by using 64-bit processors running 64-bit applications. Just about everything built in the last 15 years has already got the fix
Using that fix, the problem doesn’t come up again for about 300 billion years
You don’t need 64 bit programs or CPUs to fix the 2038 problem. You just need to use a 64 bit time_t. It will work fine on 32 bit CPUs or even 8 bit microcontrollers.
And not using 32-bit integers to calculate time. Which is still a thing in many many many codebases written in C or C++…
32 bit embedded processors us a lot of 32 bit time, though i am not sure if date time libraries in SDKs have been updated to use 64 bit for time.
Linux kernel updated to 64 bit time quite recently. In 2038 I can guarantee somebody in a very serious business is still using an ancient RHEL and will have issues.