The problem of the year 2038, which explains the error of the counter resetting in 2038 in 32-bit systems using POSIX time representation, has been resolved until 2486 with Linux 5.10.
Even though time units are simple “things” for us to perceive, as computers process data as “bits”, what computers perform may not be the same as they show us. For example, if you say “My brother was born in 95”, the person in front of you might understand that your brother was born in 1995, but for the computer, your brother was actually born in the year 95 and is 1925 years old.
The time keeping method of computers will cause 32-bit systems using some POSIX time notation to crash in 2038 after a software error known as the Year 2038 Problem, and Linux 5.10 has managed to solve this problem by 2486.
The functioning of the meter that caused the 2038 Problem
Before moving on to the solution of Linux, if we need to open up the 2038 Problem; In 32-bit UNIX and derivative systems that keep the time in seconds since January 1, 1970, on Tuesday, January 19, 2038, at 03:14:07, the counter will return to its starting point and the system date will be 20:45:52 on December 13, 1901. will show. The simplest way to eliminate the error in question was seen as a transition to 64-bit systems, which is exactly the solution Linux found.
According to the statement made by Phoronix, the “Big Time Stamp” that comes with Linux 5.10 reorganizes the timestamps and inode encoding functions to use a 64-bit nanosecond counter instead of the 32-bit time counter that reveals the Year 2038 Problem. The 64-bit counter can be used from December 1901 to July 2486, as opposed to the 32-bit time counter available from December 1901 to January 2038.