Hi friends,
I just received a mail from my friend, which i am posting here.
I just received a mail from my friend, which i am posting here.
THE YEAR 2038 BUG
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.