Short Bytes: If you follow the developments of Linux world closely, you must be knowing about the Year 2038 bug. This problem exists because the latest time that can be represented in Unix’s signed 32-bit integer time format is 03:14:07 UTC on Jan. 19, 2038. After that, the C programs that use the standard time library will start to have problems with dates.The Year 2000 problem, also known as the Millenium Bug or the Y2K problem, was a computer bug related to formatting and storage of calendar date. This problem started as the storage in early computers was expensive. So, to reduce the storage space, the programmers used the six-digit MMDDYY date format. As the programs were able to add 19 to year’s YY, it saved money but reducing the size of files and databases. However, such programs found it hard to distinguish between the year 2000, 1900, and 19100.
To tackle this issue, governments set up special committees to make sure that critical infrastructure had fixed this problem. Now, analogous to the same, the Year 2038 problem is another issue for computing world.
The Year 2038 problem is also called Unix Millenium Bug or Y2K38 bug. This bug could cause problems in the data storage situations in which time values are stored or calculated as a signed 32-bit integer.
The latest time that can be represented in Unix’s signed 32-bit int time format is 03:14:07 UTC on Jan. 19, 2038, which is 2,147,483,647 seconds after Jan. 1, 1970. Beyond that time, due to integer overflow, the time values will be stored as a negative number and the systems will read the date as Dec. 13, 1901 rather than Jan. 19, 2038.
In simple language, Unix machines are eventually going to run out of the bits to tick off seconds. So, on this day, the C programs that use the standard time library will start to have problems with dates. You can read more about the same in detail on Wikipedia.
Here’s an animation showing how the Year 2038 bug would reset the date:
At the moment, there’s no universal solution for the Year 2038 bug. If a change would be made to the definition of the time_t data type, which is used to store time values, there would be some code compatibility problem in applications that dependent on the nature of signed 32-bit time_t integer. Let’s suppose type of time_t is changed to an unsigned 32-bit integer, which would increase the latest time limit. But, it would mess with the dates prior to 1970, which are represented by negative integers.
The operating systems and programs using 64-bit architecture use 64-bit time_t integers. Using a signed 64-bit value introduces the dates up to 292 billion years from now.
There have been many proposals made, including storing milliseconds/microseconds since an epoch (Jan. 1, 1970 or Jan. 1, 2000) in a signed 64-bit int to get a minimum range of 300,000 years. Other suggestions deal with recompiling programs with a new library, etc. Well, the work is ongoing and, according to the experts, the Year 2038 problem shouldn’t be much hard to fix.
Did you find this story on the Year 2038 problem in Linux interesting? Share your views with us.