Pro7 wrote:
<font color="pink">
really? I must have missed that part. I naturally thought he needed it for the unix problem. [/COLOR]
Hmmmmm.....
Please read:
Quoted John regarding IBM machine:
"JOHN: On my worldline, it is known that the 5100 series is capable of
reading all the IBM code written before the widespread use of APL and Basic.
JOHN: In 2036, it was discovered (or at least known after testing) that the
5100 computer was capable of reading and changing all of the legacy code
written by IBM before the release of that system and still be able to create
new code in APL and basic. That is the reason we need it in 2036. However,
IBM never published that information because it would have probably
destroyed a large part of their business infrastructure in the early 70s. In
fact, I would bet the engineers were probably told to keep their mouths
shut.
JOHN: Therefore, if I were not here now telling you this, that information
would not be discovered for another 36 years. Yet, I would bet there is
someone out there who can do the research and discover I am telling the
truth. There must be an old IBM engineer out there someplace that worked on
the 5100. They just might not have ever asked if I hadn't pointed it out.
JOHN: The 5100 has the ability to easily translate between the old IBM code,
APL, BASIC and (with a few tweaks in 1975) UNIX. This may seem insignificant but the fact that the 5100 is portable means I can easily take it back to 2036. I do expect they will create some sort of emulation system to use in multiple locations."
end quoted John Titor
Then, we already know about the "Friday the Thirteenth Bug", and because the end bit indicating positive/negative integer may flip over, some systems may revert the date to 20:45:52, Friday, December 13 others could even result in a system time of December 32, 1969
Some code to quick check the computers...
#!/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?
Quoted:
"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
-crunch-
Many Intel x86 platforms have BIOS date issues as well. The Linux BIOS time utility hwclock has issues around the critical second in 2038 too (DO NOT try this on a production system unless you REALLY know what you're doing):
[root@alouette root]# hwclock --set --date="1/18/2038 22:14:06"
[root@alouette root]# hwclock --set --date="1/18/2038 22:14:07"
RTC_SET_TIME: Invalid argument
ioctl() to /dev/rtc to set the time failed.
[root@alouette root]# hwclock --set --date="1/18/2038 22:14:08"
date: invalid date `1/18/2038 22:14:08'
The date command issued by hwclock returned unexpected results.
The command was:
date --date="1/18/2038 22:14:08" +seconds-into-epoch=%s
"
More at:
Project 2038 FAQ
then imagine a world whitout Java Applets...thanks to the bug...
--
Regards
Comet 17p Holmes Online Petition