Ubuntu is already immune to the 2038 bug. The Linux kernel even supports using a 64 bit time_t on 32 bit systems now. Of course some poorly written software could still be affected, but that’s not the fault of the kernel or operating system.
The 2038 bug will certainly cause problems in some embedded systems that still use a 32 bit time_t if they are still running by then.
It’s not poorly written software if it’s is old. Likewise the y2k bug is often declared as bad programming, but at the time the software with the y2k bug was written memory was measured in kilobytes and a lot of accounting software and banking software was written in a time when 64k was the norm. Oh, and I’ll tell you now I know of at least some accounting software that is based on code written for the 8088 and has been wrapped and cross compiled so many times now it’s unrecognisable. But I know that 40 year old code is still there.
So 2 digits for year was best practice at the time and at the time software vulnerable to the 2038 bug 32bit epoch dates was the best practice.
Now, software written today doing the same, could of course be considered bad, but it’s not a good blanket statement.
I mean, Ghost Recon Wildlands which came out in 2017 for example has save dates written as a 32-bit date so it’s prone to the 2038 bug, I set the date to 2040 and tested a bunch of software and while you can save the date overflows and shows as 1969. I bet there are still people using 32-bit dates even if unintentionally.
I mean, technically you could use unsigned 32bit if you don’t need to handle dates before 1970. But yes, the best course of action now is to use 64bits. The cost is pretty much nothing on modern systems.
I’m just cautious of people judging software from a time with different constraints and expectations, with the current yardstick.
I also wonder what the problem will be. People playing ghost recon in 2038 are going to be “retro” gaming it. There should be an expectation of such problems. Would it prevent you loading or saving the file is the question?
Nope, saving and loading works on that game (and pretty much every other game I tested), it’s just you lose the date display in-game so you don’t know when you really last saved.
Software also looks at future dates, so the problem is actually going to start to occur much sooner. The kernel will be fine, it’s all the other random software floating out there that you should worry about. A lot of in-house calendar and booking software is probably going to start to blow up soon.
Suspiciously all current LTS expire on Dec 2026 there is nothing planned ahead of this. And 3y for 6.6 is the shortest of any LTS I remember. My bet is Linus retiring then LF taking over everything.
So next LTS might have to be resilient to the 2038 bug (32 bit signed timestamps overflow). I wonder how many softwares are vulnerable 🤔
Ubuntu is already immune to the 2038 bug. The Linux kernel even supports using a 64 bit time_t on 32 bit systems now. Of course some poorly written software could still be affected, but that’s not the fault of the kernel or operating system.
The 2038 bug will certainly cause problems in some embedded systems that still use a 32 bit time_t if they are still running by then.
It’s not poorly written software if it’s is old. Likewise the y2k bug is often declared as bad programming, but at the time the software with the y2k bug was written memory was measured in kilobytes and a lot of accounting software and banking software was written in a time when 64k was the norm. Oh, and I’ll tell you now I know of at least some accounting software that is based on code written for the 8088 and has been wrapped and cross compiled so many times now it’s unrecognisable. But I know that 40 year old code is still there.
So 2 digits for year was best practice at the time and at the time software vulnerable to the 2038 bug 32bit epoch dates was the best practice.
Now, software written today doing the same, could of course be considered bad, but it’s not a good blanket statement.
I mean, Ghost Recon Wildlands which came out in 2017 for example has save dates written as a 32-bit date so it’s prone to the 2038 bug, I set the date to 2040 and tested a bunch of software and while you can save the date overflows and shows as 1969. I bet there are still people using 32-bit dates even if unintentionally.
I mean, technically you could use unsigned 32bit if you don’t need to handle dates before 1970. But yes, the best course of action now is to use 64bits. The cost is pretty much nothing on modern systems.
I’m just cautious of people judging software from a time with different constraints and expectations, with the current yardstick.
I also wonder what the problem will be. People playing ghost recon in 2038 are going to be “retro” gaming it. There should be an expectation of such problems. Would it prevent you loading or saving the file is the question?
Nope, saving and loading works on that game (and pretty much every other game I tested), it’s just you lose the date display in-game so you don’t know when you really last saved.
Yeah, that’s my point. It’ll be a retro game by 2038 and anyone playing it will know it’s “one of those quirks”
The bigger problem is software where the date really matters.
Software also looks at future dates, so the problem is actually going to start to occur much sooner. The kernel will be fine, it’s all the other random software floating out there that you should worry about. A lot of in-house calendar and booking software is probably going to start to blow up soon.
Suspiciously all current LTS expire on Dec 2026 there is nothing planned ahead of this. And 3y for 6.6 is the shortest of any LTS I remember. My bet is Linus retiring then LF taking over everything.
@Bogasse @ylai
Wouldnt 12 years update add up to 2036 and not 2038?
They did say next LTS