The forthcoming Linux 5.10 looks like it will include further fixes for the Year 2038 problem, aka Y2K38.
The flaw means that many systems can’t conceive of dates beyond 03:14:07 UTC on 19 January 2038.
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.
But perhaps because 2038 is still rather far off, little has been done and that worries the likes of long-time Linux kernel chronicler Jon Corbet.
Behold Schrödinger's Y2K, when software went all quantumREAD MORE
Happily, work has started on the issue: Linux 5.6 promised to outlive 2038.
And now some filesystem fixes have popped up for Linux 5.10.
As spotted by the kernel-watchers at Phoronix and posted to the Linux kernel mailing list, Oracle filesystem developer Darrick J. Wong has submitted code for XFS that he says will “support timestamps until the year 2486.”
The proposed changes will widen ondisk inode timestamps and ondisk quota expiration timestamps to handle dates beyond 2038.
Which should mean that Linux, at least, remains capable of operation past Y2K38.
If Linus Torvalds keeps to his usual cadence of a new release about every eight weeks, the waiting world will have the fix before Christmas and therefore with just over 17 years to get this part of the Y2K38 mess nipped in the bud.
Assuming enough of humanity outlives COVID-19 to care for that long. ®