Almost everyone with some relation to ICT clearly remembers the millennium bug that preceded the internet bubble in 2001. The problem was caused by date formats that were written with a two number format for years (e.g. 00-00-00). On midnight, at the start of the new millennium, the 99 for the year would be changed to 00 again, making software programs believe that the new year would be 1900 instead of 2000. With the Millennium problem solved ten years ago, programmers are now looking into the future and found another time-related bug that might break many programs.
The UNIX time format described points in time by looking at their relative position compared to midnight of January 1, 1970 (UTC), while not counting leap seconds. In other words, January 1, 1970 is the zero of the UNIX time format and since then every second the UNIX time has been increased with one second. At the moment of writing, the UNIX time is around 1289227433 and it is steadily increasing to ranges that can cause problems for software. You can view the current UNIX time online.
The year 2038 problem
Through the years, many software applications have adapted the UNIX time as the format to save times in databases, log files etc. Currently, this causes little problems as the year 2038 is still 28 years (or 883008000 seconds) in the future. But on January 18, 2038 at 03:17:07 (UTC) the UNIX time will reach 2,147,483,647 seconds, the maximum value represented by a signed integer in 32-bit. One second later, the integer will be reset to its lowest value of minus 2,147,483,648 and thus represent December 13, 1901 20:45:52 (UTC) which will be problematic for software used worldwide. This problem has been named the ‘year 2038 problem’ and has been compared to the Millennium bug many times (that is why this bug is also known as the ‘Unix Millennium Bug’).
There is no straightforward solution for this problem, because many software applications and platforms differ in their usage and requirements for the time format used. Several proposals have been made and can be used as a fix to this problem depending on the requirements for the time format. First of all an unsigned integer can be used to modify the range by an additional 2,147,483,648 seconds to 4,294,967,295. The drawback of this fix is that the negative range of UNIX times will no longer be available, which will cause problems for software that have dates before January 1, 1970. A second solution is to use 64-bit integer for the storage of UNIX times, which will increase the range of the UNIX time dramatically. This however requires hardware changes that are costly and it is highly unlikely that all 32-bit systems will have been replaced by 2038 as they are widespread. A third solution might be to use a different format to save a moment in time like DateTime (ISO 8601). This solution would not require new hardware and extend the range available by hundreds of years, but might require many changes to the software.
As we are nearing the deadline to solve this time-related problem, programmers should start to think about the impact of the year 2038 problem on their software. There are several solutions available (which were not all mentioned in this article) and developers should decide which solution fits their program best before implementing it. With 28 years of time available to fix the problem, it is expected that many software packages can be updated in time to overcome this issue. Whether this will actually happen in time, only time will tell…