357

submitted 1 week ago by cm0002@lemmy.world to c/programmer_humor@programming.dev

22 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] juliebean@lemm.ee 53 points 1 week ago

hopefully by then it'll all be sorted by whatever fix they implemented before 2038.

[-] MartianSands@sh.itjust.works 27 points 1 week ago

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

[-] pimeys@lemmy.nauk.io 22 points 1 week ago

And not using 32-bit integers to calculate time. Which is still a thing in many many many codebases written in C or C++...

[-] JustEnoughDucks@feddit.nl 3 points 1 week ago

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.

[-] pimeys@lemmy.nauk.io 5 points 1 week ago

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.

[-] ulterno@programming.dev 0 points 1 week ago

With people turning back system time to use their Trial Software forever all the time, already causing problems with GitLab history, I feel like not many will blink at that.