The Year 2038 Problem

Discussion in 'The ChitChat Lounge' started by amit82cse, Feb 8, 2006.

  1. amit82cse

    amit82cse Silent observeR

    The Year 2038 Problem

    What is it?
    Starting at GMT 03:14:07, Tuesday, January 19, 2038, It is expected to see lots of systems around the world breaking magnificently:

    satellites falling out of orbit, massive power outages (like the 2003 North American blackout), hospital life support system failures, phone system
    interruptions, banking errors, etc. One second after this critical second, many of these systems will have wildly inaccurate date settings,
    producing all kinds of unpredictable consequences. In short, many of the dire predictions for the year 2000 are much more likely to actually occur in
    the year 2038! Consider the year 2000 just a dry run. In case you think we can sit on this issue for another 30 years before addressing it, consider
    that reports of temporal echoes of the 2038 problem are already starting to appear in future date calculations for mortgages and vital statistics!
    In the first month of the year 2038 C.E. many computers will encounter a date-related bug in their operating systems and/or in the applications
    they run. This can result in incorrect and wildly inaccurate dates being reported by the operating system and/or applications. The effect of this
    bug is hard to predict, because many applications are not prepared for the resulting "skip" in reported time - anywhere from 1901 to a "broken
    record" repeat of the reported time at the second the bug occurs. Also, may make some small adjustment to the actual time the bug expresses itself. This
    bug to cause serious problems on many platforms, especially Unix and
    Unix-like platforms, because these systems will "run out of time".

    What causes it?

    Time_t is a data type used by C and C++ programs to represent dates and
    times internally. (Windows programmers out there might also recognize it as the basis for the CTime and CTimeSpan classes in MFC.)

    time_t is actually just an integer, a whole number, that counts the number of seconds since January 1, 1970 at 12:00 AM Greenwich Mean Time.

    A time_t value of 0 would be 12:00:00 AM (exactly midnight) 1-Jan-1970,

    a time_t value of 1 would be 12:00:01 AM (one second after midnight) 1-Jan-1970, etc..
    some example times and their exact time_t representations:

    Date & time time_t representation

    1-Jan-1970, 12:00:00 AM GMT 0

    1-Jan-1970, 12:01:00 AM GMT 60

    1-Jan-1970, 01:00:00 AM GMT 3 600

    2-Jan-1970, 12:00:00 AM GMT 86 400

    1-Jan-1971, 12:00:00 AM GMT 31 536 000

    1-Jan-1972, 12:00:00 AM GMT 63 072 000

    1-Jan-2038, 12:00:00 AM GMT 2 145 916 800

    19-Jan-2038, 03:14:07 AM GMT 2 147 483 647

    By the year 2038, the time_t representation for the current time will be over 2 140 000 000. And that's the problem. A modern 32-bit computer
    stores a "signed integer" data type, such as time_t, in 32 bits. The first of these bits is used for the positive/negative sign of the integer,
    while the remaining 31 bits are used to store the number itself. The highest number these 31 data bits can store works out to exactly 2 147 483 647.
    A time_t value of this exact number, 2 147 483 647, represents January 19, 2038, at 7 seconds past 3:14 AM Greenwich Mean Time.

    So, at 3:14:07 AM GMT on that fateful day, every time_t used in a 32-bit C or C++ program will reach its upper limit.

    One second later, on 19-January-2038 at 3:14:08 AM GMT, disaster strikes.

    When a signed integer reaches its maximum value and then gets incremented,it wraps around to its lowest possible negative value. This means a
    32-bit signed integer, such as a time_t, set to its maximum value of 2 147 483 647
    and then incremented by 1, will become -2 147 483 648. Note that "-" sign at the beginning of this large number.

    A time_t value of -2 147 483 648 would represent December 13, 1901 at 8:45:52 PM GMT.
    So, if all goes normally, 19-January-2038 will suddenly become 13-December-1901 in every time_t across the globe, and every date
    calculation based on this figure will go haywire. And it gets worse. Most of the support functions that use the time_t data type cannot handle
    negative time_t values at all. They simply fail and return an error code. A quick check with the following Perl script may help determine if your
    computers will have problems (this requires Perl to be installed on your system, of course):

    # Use POSIX (Portable Operating System Interface)
    use POSIX;
    # Set the Time Zone to GMT (Greenwich Mean Time) for date calculations.
    $ENV{'TZ'} = "GMT";
    # Count up in seconds of Epoch time just before and after the critical
    for ($clock = 2147483641; $clock < 2147483651; $clock++)
    print ctime($clock);

    For example, the output of this script on Debian GNU/Linux (kernel
    (An affected system) will be
    # ./
    Tue Jan 19 03:14:01 2038
    Tue Jan 19 03:14:02 2038
    Tue Jan 19 03:14:03 2038
    Tue Jan 19 03:14:04 2038
    Tue Jan 19 03:14:05 2038
    Tue Jan 19 03:14:06 2038
    Tue Jan 19 03:14:07 2038
    Fri Dec 13 20:45:52 1901
    Fri Dec 13 20:45:52 1901
    Fri Dec 13 20:45:52 1901


    "The best way to predict the future is to engineer it." Consider testing your mission-critical code well ahead of time on a non-production test
    platform set just before the critical date. For more general applications, just using large types for storing dates will do the trick in most

    For example, in GNU C, 64-bits (a "long " type) is sufficient to keep
    the time from rolling over for literally geological eons This just means
    any executables the operating systems runs will always get the correct time
    reported to them when queried in the correct manner. It doesn't stop the
    executables you may still want to be worried about Well-written programs

    can simply be recompiled with a new version of the library that uses,

    for example, 8-byte values for the storage format.
    This is possible because the library encapsulates the whole time activity
    with its own time types and functions (unlike most mainframe programs, which
    did not standardize their date formats or calculations). So the Year 2038
    problem should not be nearly as hard to fix as the Y2K problem was.
    Admittedly, some don't feel that this impending disaster will strike
    too many people. They reason that, by the time 2038 rolls around, most
    programs will be running on 64-bit or even 128-bit computers. In a 64-bit
    program, a time_t could represent any date and time in the future out to 292 000
    000 000 A.D., which is about 20 times the currently estimated age of the
    universe. The problem with this kind of optimism is the same root
    problem behind most of the Year 2000 concerns that plagued the software
    industry in previous years: Legacy Code. Even if every PC in the year 2038 has a
    64-bit CPU, there will be a lot of older 32-bit programs running on them
    The greatest danger with the Year 2038 Problem is its invisibility. The
    more-famous Year 2000 is a big, round number; it only takes a few
    seconds of thought, even for a computer-illiterate person, to imagine what
    might happen when 1999 turns into 2000. But January 19, 2038 is not nearly as
    obvious. Software companies will probably not think of trying out a
    Year 2038 scenario before doomsday strikes. Of course, there will be some
    warning ahead of time. Scheduling software, billing programs, personal
    reminder calendars, and other such pieces of code that set dates in the
    near future will fail as soon as one of their target dates exceeds
    19-Jan-2038, assuming a time_t is used to store them.
    Good luck, and hope no ones flying car breaks down in 2038
  2. knight_guitar

    knight_guitar Lead Guitarist

    I don't understand.. who works in C-shell these days..

    And above all ok if u talking about time_t u must be knowing that.. we all have "Time.h" in compilers we use and any header files function can be changed so i don't think so .. we should actually start worrying about 2038 in 2006 (it's way to far, and trust me no one actually works on C-shell these days) we've moved to korn-shell these days although it doesn't matter which shell we write the shell scripts but it's way too far and this gonna be solved for sure..
  3. death_metal_fan

    death_metal_fan oh goody, it's a woody!

    Come on, do you honestly believe we will still be using 32-bit computers 30 years from now??? By 2038 all of us will be using 64-bit or (most likely) greater computers and programs compiled for 64-bit or greater computers. Don't tell me that 30 years is not enough time to recompile every single 32-bit program to work for a 64-bit system. In fact I am quite sure the computers of 2038 will be so amazing, so powerful and so unlike the computers of today that we cannot even begin to imagine what they will be capable of or what kind of technology they will employ. This scenario will almost certainly never occur.
  4. shsnawada

    shsnawada Cyborgs &amp; Pasta

    Believe me, pretty much every computer will crash by 2000. Thats because of the way the dates are written. Wait till 2000 and you'll see. January 1st 2000 will have major breakdowns.

    And the breakdowns wont be like the ones from the band dying fetus. Theyll be much worse.
  5. shak

    shak Harrr!

    *looks at first post* then *reads shs clever sarcasm*

    dumb machines .... !##$(&^#$!
  6. metal_fan69

    metal_fan69 To Live Is To Die

    We might have the "Quantum Computers" at that time..... which will use not only two but all the 32 states of electrons

Share This Page