2038 bug - a threat bigger than Y2K The year-2038 bug is a threat similar to the Y2K bug in that it involves a time wrap not handled by programmers. In the case of Y2K, many older machines did not store the century digits of dates, hence the year 2000 and the year 1900 would appear the same. Of course we now know that the prevalence of computers that would fail because of this error was greatly exaggerated by the media. Computer scientists were generally aware that most machines would continue operating as usual through the century turnover, with the worst result being an incorrect date. This prediction withstood through to the new millennium. Effected systems were tested and corrected in time, although the correction and verification of those systems was monumentally expensive. There are however several other problems with date handling on machines in the world today. Some are less prevalent than others, but it is true that almost all computers suffer from one critical limitation. Most programs use Coordinated Universal Time (UTC) to work out their dates. Simply, UTC is the number of seconds elapsed since Jan 1 1970. A recent milestone was Sep 9 2001, where this value wrapped from 999'999'999 seconds to 1'000'000'000 seconds. Very few programs anywhere store time as a 9 digit number, and therefore this was not a problem. Modern computers use a standard 4 byte integer for this second count. This is 31 bits, storing a value of 231. The remaining bit is the sign. This means that when the second count reaches 2147483647, it will wrap to -2147483648. The precise date of this occurrence is Tue Jan 19 03:14:07 2038. At this time, a machine prone to this bug will show the time Fri Dec 13 20:45:52 1901, hence it is possible that the media will call this The Friday 13th Bug. Solution: Our 32-bit root servers currently use the FreeBSD 4.7 operating system. As with all Unix and Unix-like operating systems, time and dates in FreeBSD are represented internally as the number of seconds since the UNIX Epoch, which was the 1st of January 1970 GMT. 32-bit systems can only store a maximum of 231 non-negative seconds (2,147,483,648 seconds or about 68 years). Which means that 32-bit UNIX systems won't be able to process time beyond 19 Jan 2038 at 3:14:07 AM GMT. One of the common solutions will be to switch to 64-bit architecture systems that can store a maximium of 263 non-negative seconds (9,223,372,036,854,775,808 [9.2 Quintillion] seconds or about 292.27 Billion years), which is about 22 times the estimated age of our universe! For the curious: A switch to 128-bit architecture systems would yield a maximum of 2127 non-negative seconds (170,141,183,460,469,231,731,687,303,715,884,105,728 [170 Undecillion] seconds), or about 18.4 Quintillion times as many as 64-bit systems