https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.18-More-Y2038-Prep
The Linux kernel has already been prepping for years for Year 2038 and that work is still ongoing with the in-development Linux 4.18 kernel.
The Year 2038 problem is when systems using a signed 32-bit integer for storing the time since 1 January 1970 (standard for the Unix time-stamp) will wrap around.
Solving the Year 2038 problem in the Linux kernel
https://opensource.com/article/19/1/year2038-problem-linux-kernel
6 Comments
Tomi Engdahl says:
Because of the way time is represented in Linux, a signed 32-bit number can’t support times beyond January 19, 2038 after 3:14:07 UTC. This Year 2038 (Y2038 or Y2K38) problem is about the time data type representation. The solution is to use 64-bit timestamps.
https://opensource.com/article/19/1/year2038-problem-linux-kernel
Tomi Engdahl says:
more on the Unix 2038 time 32 bit integer coming apocalypse #y2k38 #y2k #y2038
Year 2038
Unix time rollover
Main article: Year 2038 problem
The original implementation of the Unix operating system stored system time as a 32-bit signed integer representing the number of seconds past the Unix epoch: midnight UTC, 1 January 1970. This value will roll over on 19 January 2038. This problem has been addressed in most modern Unix and Unix-like operating systems by storing system time as a 64-bit signed integer, although individual applications, protocols, and file formats will still need to be changed as well.
https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2038
https://www.unixtimeconverter.io/
https://www.unixtimestamp.com/
Tomi Engdahl says:
Need 32-bit Linux to run past 2038? When version 5.6 of the kernel pops, you’re in for a treat
I’ve been to the year 3000… Not much has changed, but they’re still patching Linux
https://www.theregister.com/2020/01/30/linux_5_6_2038/
Linux fans intent on holding back the years will be delighted to hear that the upcoming version 5.6 of the kernel should see 32-bit systems hanging on past the dread Y2038.
Arnd Bergmann, an engineer working on the thorny Y2038 problem in the Linux kernel, posted to the mailing list that, yup, Linux 5.6 “should be the first release that can serve as a base for a 32-bit system designed to run beyond year 2038″.
Tomi Engdahl says:
Linux 5.10 Solves the Year 2038 Problem Until 2486
https://linux.slashdot.org/story/20/10/17/2237236/linux-510-solves-the-year-2038-problem-until-2486?
utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Slashdot%2Fslashdot%2Fto+%28%28Title%29Slashdot+%28rdf
%29%29
Linux 5.10 to make Year 2038 problem the Year 2486 problem
XFS timestamp tweak extends Unix time for a few centuries
https://www.theregister.com/2020/10/19/linux_5_10_y2k38_fixes/
Y2K was caused by systems representing years with two digits and assuming that a year ending with two zeroes would be 1900. Y2K38 is different because it’s derived from Unix and Unix-like systems counting time since January 1st, 1970 in seconds. Come January 19th, 2038, that number will be a bigger value than can be stored as a single 32-bit integer. At which point, things could get interesting.
The need to remedy the Y2K38 problem has been known before the Y2K problem erupted into the public imagination, proved the world’s most expensive and unspectacular piece of proactive maintenance and inevitably spawned truthers who suggest the whole thing was a hoax dreamed up to make work for the computing services industry.
Tomi Engdahl says:
Linux Kernel 5.6 Ready To Fix Year 2038 Problem
https://fossbytes.com/linux-kernel-5-6-fix-year-2038-problem/
Tomi Engdahl says:
Is the Year 2038 problem the new Y2K bug?
This article is more than 5 years old
Reports proclaim that the Year 2038 problem is going to cause computerised doom: here’s what you need to know
https://www.theguardian.com/technology/2014/dec/17/is-the-year-2038-problem-the-new-y2k-bug