As computers are programmed to store the last two digits of the year only because it saves storage space, there’s only one day left in the year 1999 (99); which is a day later, therefore the systems would supposedly fail to understand if it’s the Year 2000 (00) or 1900 (00), so was the argument.
While the storage of a combination of date and time within a fixed binary field is often considered the solution, albeit the possibility for software to misinterpret dates still remains as date and time representations are relative to some known origin.
What's the Year 2038 Bug?
The Year 2038 bug is as a result of the original Unix time datatype (time_t) which stores a date and time as a signed long integer on 32-bit systems a 32-bit integer, representing the number of seconds since January 1, 1970. After 2038, this number will exceed 231 − 1, the largest representable by a signed long integer on 32-bit systems.
It will cause the Year 2038 bug, also referred to as the Unix Millennium bug, which unlike 64-bit systems which uses 64 bits, the problem doesn't exist on 64-bit systems as they use the LP64 model.
And the maximum value of a 32-bit interger, which is 2,147,483,647 will starting from 19th January 2038, at exactly 3:14:07, result to the value of stored time since January 1, 1970 to equal the value of a 32-bit integer, that is, 2,147,483,647, thereby causing the issue.
How Linux Kernel 5.10 Solves the Year 2038 Bug
The XFS file system in Linux Kernel 5.10 has been extended to the year 2486, which change fixes the Year 2038 bug. With “Large Timestamps” function that has now fixed this problem by refactoring their timestamp and inode encoding; and the timestamps will now be dealt with as a 64-bit nanosecond counter and bit shifting to extend the measurement.
It is made possible by a brand new XFS file-system with bigtime enabled, which permits the timestamp from December 1901 to July 2486, and for the preservation of backward compatibility, the large timestamps function isn't enabled by default.
Thus, XFS also takes care of the year 2038 problem, whereby the storing of the time since 1970 in seconds will now not slot in a signed 32-bit integer and a wraparound till the year 2486.
No comments