I'm Back!!
LINUX 38 which is also know as Linux 2038.
LINUX 38 which is also know as Linux 2038.
Linux 2038 is similar to Y2K problem. Y2K is also know as Millennium bug, at the begin of century 2000 many non-Y2K compliant software and hardware systems may interpret the year 2000 as 1900, since they interpret year with last two digits i.e 1900 as 00 and 1999 as 99, so year 2000 would be represented as 00, so is it representing 1900 or 2000 ? but which actually represented 1900, this is know as Y2K.
The year 2038, January 19th GMT 03:14:07 after this critical second, computer system which includes an Unix systems - Operating system or Embedded hardware system, or an Application may show incorrect or confusing date. This Linux 38 bug may cause worldwide system failures, especially the system which running on Unix or Unix flavours.
The most of the Unix or Unix flavours Operating system used in the devices such as LCD TVs, Hospital Life support system, Satellite systems, Car dashboard navigation system, Space probe systems, many legacy systems, Servers which still has 32 bit platform and many more like, which may incur huge transition cost for fixing the bug.
The root cause of the bug is that, many Unix or Unix flavour Operating system do not calculate time in terms of Georgian calendar, but simply they count up the seconds since the reference time GMT 00:00:00 Thursday, January 1, 1970 C.E .
Unix uses 32 bit signed time_t (which is integer) so largest possible value this integer can hold up is 2,147,483,647 which corresponds to GMT 3:14:07, Tuesday, January 19, 2038 since their reference time. One second later after this critical second, the Unix system may revert to their reference time which is GMT 00:00:00 1970 C.E because of the end sign bit, which may flip over. Following information I compiled from the Internet, the below information helps each system identifying the computer which may fall prey to the bug.
This is perl scrip.
#!/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 < 2147483651; $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?
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
The only solution from my point of view is upgrading the hardware and software system from 32-bit to 64 bit.
#
# 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 < 2147483651; $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?
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
The only solution from my point of view is upgrading the hardware and software system from 32-bit to 64 bit.
From technical point of view ,this bug will cause a major disastrous to many organization, many Embedded hardware system, financial crisis. Lets prepare ourself for the worst. :)
