The Year 2000 problem was one of the most severe issues in programs of computerized systems that created havoc in computers and affecting systems worldwide. A little background on why this problem emerged — Ever noticed when a computer or a website asks you to enter the last two digits of the year?
Computers are programmed to store only the last two digits of years because it saves storage space (Four digits Vs. Two digits). Say there’s only one day left in the year 1999 (99); a day later, the systems would fail to understand if it’s the Year 2000 (00) or 1900 (00).
The Year 2038 Problem: Solution
A problem similar to Y2k was supposed to arrive in the year 2038 but thanks to the XFS file system in Linux 5.10, it has been extended to the year 2486. The changes made to fix this problem are —
Recording the size of inode btrees in the allocation group increases redundancy checks and allows faster mount times.
2,147,483,647 is the maximum value of a 32-bit interger. On Tuesday, 19th January 2038, exactly at 3:14:07, the value of stored time since 1st January 1970 will equal the value of a 32-bit integer, i.e., 2,147,483,647, causing the issue. Here’s a short animation that illustrates what would have happened —
Also Read: What is the Year 2038 in Linux and Unix
“A “Large Timestamps” function has now fixed this by refactoring their timestamp and inode encoding feature. Due to this, timestamps will now be dealt with as a 64-bit nanosecond counter and bit shifting to extend the efficient measurement,” said the folks over Phoronix in this article.
Adding to that, they said, “XFS can now take care of the previous year 2038 problem (the place storing the time since 1970 in seconds will now not slot in a signed 32-bit integer and thus wraparound) till the year 2486. This was made possible by Making a brand new XFS file-system with bigtime enabled, which has now permitted the timestamp from December 1901 to July 2486. For preserving backward compatibility, the large timestamps function is not at present enabled by default.”
