Try this First.
Sign out from yahoo messenger or gmail talk. Open your System Date and Time Settings. Change the year to anything beyond 2038. You can try setting the year to 2040. Now try logging in to either of the messenger. It does not log in and gives you some error. Surprised!
So, Where's the problem ?
The source of the problem is actually the way some(major) applications store their date/time data types. Programmes using POSIX time representation will be affected by this problem. 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. As I said, 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. Applications written in C in many operating system will also be affected as the POSIX presentation of time is widely used there. The animation below visualizes actual scenario in an easier manner. This bug is often denoted as "Y2038", "Y2K38", or "Y2.038K" bug.
Simulate the bug in a C Programme.
The following ANSI C programme when compiled simulates the bug. The output produced by the programme is also attached below the code. This code has been been referred from here.
Collapse
#include
#include
#include
#include
int main (int argc, char **argv)
{
time_t t;
t = (time_t) 1000000000;
printf ("%d, %s", (int) t, asctime (gmtime (&t)));
t = (time_t) (0x7FFFFFFF);
printf ("%d, %s", (int) t, asctime (gmtime (&t)));
t++;
printf ("%d, %s", (int) t, asctime (gmtime (&t)));
return 0;
}
Output :
Collapse
1000000000, Sun Sep 9 01:46:40 20012147483647,
Tue Jan 19 03:14:07 2038-2147483648,
Fri Dec 13 20:45:52 1901
Above programme being a strict ANSI, should compile using any C compiler on any platform. Now lets take a look at a perl script on both UNIX and Windows 2000. This script has been referred from here.
Collapse
#!/usr/bin/perl #
# I've seen a few versions of this algorithm
# online, I don't know who to credit. I assume
# this code to by GPL unless proven otherwise.
# Comments provided by William Porquet, February 2004.
# You may need to change the line above to # reflect the location of your Perl binary
# (e.g. "#!/usr/local/bin/perl").
# Also change this file's name to '2038.pl'.
# Don't forget to make this file +x with "chmod".
# On Linux, you can run this from a command line like this:
# ./2038.pl use POSIX;
# Use POSIX (Portable Operating System Interface),
# a set of standard operating system interfaces.
$ENV{'TZ'} = "GMT";
# Set the Time Zone to GMT (Greenwich Mean Time) for date
# calculations.
for ($clock = 2147483641; $clock <>
print ctime($clock); }
# Count up in seconds of Epoch time just before and after the
# critical event.
# Print out the corresponding date in Gregorian calendar
# for each result.
# Are the date and time outputs correct after the critical
# event second?
A mere handful of operating systems appear to be unaffected by the year 2038 bug so far. For example, the output of this script on Debian GNU/Linux (kernel 2.4.22):
# ./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
Windows 2000 Professional with ActivePerl 5.8.3.809 fails in such a manner that it stops displaying the date after the critical second :
C:\>perl 2038.pl
Mon Jan 18 22:14:01 2038
Mon Jan 18 22:14:02 2038
Mon Jan 18 22:14:03 2038
Mon Jan 18 22:14:04 2038
Mon Jan 18 22:14:05 2038
Mon Jan 18 22:14:06 2038
Mon Jan 18 22:14:07 2038
Do we have a solution ?
Yes, Of course, There have been many solutions proposed worldwide for this problem. Few of them are listed here.
1.) Re-define the time_t structure as 64-bit.
This is not a solution as the binary compatibility of the software would break here. Programmes depending on the binary representations of time would be in trouble. So we can not even think of this one.
2.) Change time_t from 32-bit signed to 32-bit unsigned.
This seems to be good at first look, but this would just delay(post-pone) the judgement day to the year 2106 as it will give some more scope by adding another usable bit. You will be in the same trouble by then. So this is a feasible solution but not a practical one.
3.) Shift from 32-bit systems to 64-bit systems.
Most 64-bit architectures use 64 bit storage to represent time_t. The new wrap-around date with this new (signed)64 bit representation will not come before 290 billion years. It is positively predicted that by the year 2038 all 32-bit systems will be phased out and all systems will be 64-bit.
No comments:
Post a Comment