CURRENT TECHNOLOGY<br /><ul><li>Currently all software and systems that store system time as a signed 32bit integer, and interpret this number as the number of seconds since 00:00:00 January 1, 1970.</li></li></ul><li>THE Y2K38 PROBLEM<br /> The latest time that can be represented this way is 03:14:07 UTC on Tuesday, 19 January 2038. Times beyond this moment will "wrap around" and be stored internally as a negative number, which these systems will interpret as a date in 1901 rather than 2038.<br />
WHERE’S THE PROBLEM<br /><ul><li> The structure time_t is a value type which stores time in a 32-bit signed integer. It stores the time as number of seconds elapsed since January 1, 1970.
So it is capable of representing time which can be addressed within total of 231 seconds.
According to this, the latest time that it can store is 03:14:07 UTC, Tuesday, January 19, 2038. After this time, the sign bit of the 32-bit signed integer will be set and it will represent a negative number. </li></li></ul><li>WRAP AROUND DATE<br /> The time is stored as number of seconds elapsed since 1st January 1970, this negative number will be added to compute the time as per the POSIX standards. But this being a negative number it will calculate the time by subtracting this many seconds from 1st January 1970 which will eventually generate a historical date-time which will cause the applications to fail. This time will be Friday, December 1901 and is called the wrap-around date<br />
WHY IS THE PROBLEM<br /><ul><li>Y2K38 problems arise from programs not allocating enough bits to internal time.
Unix internal time is commonly stored in a data structure using a long int containing the number of seconds since 1970.
In a 32-bit machine, this value is sufficient to store time up to 18-jan-2038. After this date, 32-bit clocks will overflow and return erroneous values such as 32-dec-1969 or 13-dec-1901. </li></li></ul><li>2,147,483,647<br />
2147483648, Fri Dec 13 20:45:52 1901</li></li></ul><li>LIVE EXAMPLE<br /><ul><li>In May 2006, reports surfaced of an early Y2038 problem in the AOL Server software. The software would specify that a database request should "never" time out by specifying a timeout date one billion seconds in the future. One billion seconds (just over 31 years 251 days and 12 hours) after 21:27:28 on 12 May 2006 is beyond the 2038 cutoff date, so after this date, the timeout calculation overflowed and calculated a timeout date that was actually in the past, causing the software to crash.[</li></li></ul><li>THE COUNTDOWN BEGINS<br /><ul><li>32-bit CPUs may be obsolete in desktop computers and servers by 2038.
Most programs maybe affected in or very close to 2038.
Hardware, such as clock circuits, which has adopted the Unix time convention, may also be affected if 32-bit registers are used.
This will likely cause problems for users of these systems due to erroneous calculations</li></li></ul><li>Similar Problems<br /><ul><li>IBM PC hardware suffers from the Year 2116 problem. For a PC, the beginning of time starts at January 1, 1980, and increments by seconds in an unsigned 32-bit integer in a manner similar to UNIX time. By 2116, the integer overflows.
Windows NT uses a 64-bit integer to track time. However, it uses 100 nanoseconds as its increment and the beginning of time is January 1, 1601, so NT suffers from the Year 2184 problem. </li></li></ul><li>SOLUTION<br /><ul><li>Re-define the time_t structure as 64-bit.
Change time_t from 32-bit signed to 32-bit unsigned.
Shift from 32-bit systems to 64-bit systems.</li></li></ul><li>ANY QUERIES?<br />ANY QUERIES?<br />