This is a short blog aimed at bringing together a lot of great content already published by many individuals. The issue is the year 2038 issue, also known as Unix Millennium bug, “Y2K38” and many others.

The issue is encountered when a user sets their system date to a year past 2038 (actually it seems the date has to be past January 19, 2038) weird things happen as a result of the date calculation that is performed by the OS. You see, most Unix-like computers calculate system time as the number of seconds since the very beginning of January 1, 1970 (excluding leap years). Since a lot of applications were written in “C” or other variations of it, the date data was stored as a 32 bit signed integer. At one point in time (the year 2038), the number will overflow the 32 bit space assigned to it and will start calculating as a negative number, which when translated back to friendly time format, it looks like the year 2039 is actually the year 1939, and so on. Where there are system date dependencies, as the application encounters a date too far in the past it may fail to function. OS may suffer in terms of activation, validation, Service Packs, Hot Fixes, etc.

Most of these problems were detected and ironed out by the use of KBs or service packs in the past dozen years, but anything that has not been fixed and is still using C/C++ time in 32 bit format will basically break in the year 2038.

You can review the following links for more information:

http://blogs.msdn.com/mthree/archive/2008/04/21/year-2038-042108.aspx

http://en.wikipedia.org/wiki/Year_2038_problem

You can also search for “KB 2038” in MSDN (or follow the link below)

http://social.msdn.microsoft.com/Search/en-US?query=KB%202038&ac=8