The 2038 Bug

Depending on your point of view, the Year 2000 (Y2K) "bug" was either a lot of hot air, a shining example of crisis prevention, or a major disappointment (especially if you sold your home to buy dehydrated food and guns). But now, there's another data "bug" on the horizon.



It's being called the "2038 bug," and it's caused by how computers measure Coordinated Universal Time (UTC), a global time standard. Modern computers calculate UTC by counting the number of seconds that have elapsed since Jan. 1, 1970 (sometimes called the "Unix epoch," as this method was originally developed for Unix), storing it as an integer instead of a calendar date. As of the moment of this posting, 1,105,118,249 seconds have elapsed since the Unix epoch. This is a stable and reliable way of keeping time... and is one reason why most computers were unaffected by Y2K.



But what happens when the date integer grows too large for computers to manage properly? There was some concern that this would be a problem on Sept. 9, 2001, when the Unix epoch passed the one-billion-second point. The next milestone, however, will occur when the amount of memory allocated for the integer is exhausted and the date could be corrupted.



Using this calculation, 32-bit computers will reach this date at precisely 3:14 AM GMT on Tuesday, January 19, 2038. The bug could cause the date integer to flip to a negative number, yielding a date of Friday, Dec. 13, 1901 (hence the bug's other name, the "Friday the 13th bug").



The good news, however, is that the bug is easily corrected by increasing the number of bytes dedicated to storing the date (already done in 64- and 128-bit architectures). Also good news is that we have 33 years to upgrade our systems.



To check your computer's vulnerability to the 2038 bug, run this script.



Sources: Lockergnome, GSP.com