bored2k
May 5th, 2005, 01:41 AM
I got today this e-mail with some interesting issues. We have about 30 years to fix this so it's no biggie ^_^
> The Year 2038 Problem
>
>Test it now...
>
>steps...
>
>1. login to yahoo messenger
>2. send instant message to anyone - fine its working...
>3. now, change ur system date to 19-Jan-2038, 03:14:07 AM or above (as
>mentioned in mail)
>4. Confirm weather ur date is changed
>5. again send instant message to anyone...
>
>Your YM crahes....
>
>* * * YES ALL NETWORK BASED APPLICATION WILL NOT WORK NOW * * *
>
>Why.....
>
>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):
>
>#!/usr/bin/perl
># 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 event.
>for ($clock = 2147483641; $clock < 2147483651;
>$clock++)
>{
>print ctime($clock);
>}
>
>For example, the output of this script on Debian GNU/Linux (kernel 2.4.22)
>(An affected system) will be
>
># ./2038.pl
>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
>
>Solution
>
>"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 cases.
>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
>
>Please follow the links for more Info :
>http://www.howstuffworks.com./question75.htm
>http://www.deepsky.com/~merovech/2038.html
>http://www.deepsky.com/~merovech/2038.html
>http://www.deepsky.com/%7Emerovech/2038.html
>http://pw2.netcom.com/~rogermw/Y2038.html
>http://pw2.netcom.com/~rogermw/Y2038.html
>http://pw2.netcom.com/%7Erogermw/Y2038.html
> The Year 2038 Problem
>
>Test it now...
>
>steps...
>
>1. login to yahoo messenger
>2. send instant message to anyone - fine its working...
>3. now, change ur system date to 19-Jan-2038, 03:14:07 AM or above (as
>mentioned in mail)
>4. Confirm weather ur date is changed
>5. again send instant message to anyone...
>
>Your YM crahes....
>
>* * * YES ALL NETWORK BASED APPLICATION WILL NOT WORK NOW * * *
>
>Why.....
>
>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):
>
>#!/usr/bin/perl
># 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 event.
>for ($clock = 2147483641; $clock < 2147483651;
>$clock++)
>{
>print ctime($clock);
>}
>
>For example, the output of this script on Debian GNU/Linux (kernel 2.4.22)
>(An affected system) will be
>
># ./2038.pl
>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
>
>Solution
>
>"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 cases.
>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
>
>Please follow the links for more Info :
>http://www.howstuffworks.com./question75.htm
>http://www.deepsky.com/~merovech/2038.html
>http://www.deepsky.com/~merovech/2038.html
>http://www.deepsky.com/%7Emerovech/2038.html
>http://pw2.netcom.com/~rogermw/Y2038.html
>http://pw2.netcom.com/~rogermw/Y2038.html
>http://pw2.netcom.com/%7Erogermw/Y2038.html