You hear the one about the COBOL programer? In 1999 many people were worried about a bug with dates that could crash their systems. Unfortunately, a lot of really important systems were still using the outdated COBOL programing language. A search was done to find someone who could fix these systems. The last programmer who knew COBOL was found and they made a lot of money fixing up these systems. So much money that, once they received a cancer diagnosis, they cyrogenically froze themselves hoping that a cure for their disease would be found in the future. The programmer is awoken one day in a lab filled with high tech robotics. A person who is seemingly half machine themseves stands before them. The programmer asks “Have you found a cure for my disease?”. The person replies “We have cured all diseases. You are the COBOL programmer, correct?” “That’s right” “Great! It is the year 9999 and we have a problem we need your help with.”
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.
Still no dynamic allocation of strings in 9999? :(
strings ?
