Y2K: Hoax, Or Averted Disaster?

Allnighterking writes "Y2K -- remember the fear it generated? Cartoons were written about it. The dried food industry saw a boom. Doomsayers abounded. But in the end, no planes fell, no one died and the electric grid stayed up for three more years. Was it all a hoax? Or was it the result of careful and complete planning and upgrading. American RadioWorks has a series of articles talking about the disaster that never happened called Y2K You can either Listen in or read the Transcripts of each of the 3 broadcasts and decide for yourself. The over 100 Billion pumped into the US economy alone may well have fueled the boom and predicated the bust. Could the success at Y2K prevention have made the coming problem in 2038 something people will ignore?"

Comments

2038bug.com mirror

[Esine]

The site seems to be slashdotted already..
mirror: http://mirrordot.org/stories/c3714b90fba0ed06b444a 81bc488a392/index.html

Re:Collective fear

[blane.bramble]

No, it was two things - firstly it was a genuine problem with many back-end financial (and other) systems that had a huge amount of effort and expense spent on them and were fixed, invisibly (to the general public) thanks to a great effort by many in the IT industry. Secondly it was an over-hyped problem that was never really going to affect desktop PC's and the like, which was over-sold to the public and never materialised.

So, for most people's point of view it was a lot of fuss about nothing, because they never saw the real problem, which could have caused serious problems, and only saw the hyped, non problem.

Disclaimer: I did technical support for a Y2K team for a large bank. I know what I'm talking about. I saw the systems that would fail, and what it would do. I saw them fixed.

Perl Script

[derphilipp]

A little perl script you can use on your server to check if you are already 2038 ready:

#!/usr/local/bin/perl

use POSIX;
$ENV{'TZ'} = "GMT";

for ($clock = 2147483641; $clock < 2147483651; $clock++) {
print ctime($clock);
}

# Correct output is the following:
#
# 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 <-- Last second in 32-bit Unix systems
# Tue Jan 19 03:14:08 2038
# Tue Jan 19 03:14:09 2038
# Tue Jan 19 03:14:10 2038

(Shamelessly stolen from http://www.gsp.com/2038/ )

Re:Mirror?

[rtt]

Copy&Paste:

Update: 01/2004 The first 2038 problems are already here. Many 32-bit programs calculate time averages using (t1 + t2)/2. It should be quite obvious that this calculation fails when the time values pass 30 bits. The exact day can be calculated by making a small Unix C program, as follows:

echo 'long q=(1UL<<30);int main(){return puts(asctime(localtime(&q)));};' > x.c && cc x.c && ./a.out

In other words, on the 10th of January 2004 the occasional system will perform an incorrect time calculation until its code is corrected. Thanks to Ray Boucher for this observation.

The temporary solution is to replace all (t1 + t2)/2 with (((long long) t1 + t2) / 2) (POSIX/SuS) or (((double) t1 + t2) / 2) (ANSI). (Note that using t1/2 + t2/2 gives a roundoff error.)

The year-2038 bug is similar to the Y2K bug in that it involves a time wrap not coped for by programmers. In the case of Y2K, many older machines did not store the century digits of the date year, hence the year 2000 and the year 1900 would appear the same.

Of course we now know that the prevalence of computers that would fail because of this error was greatly exaggerated by the media. Computer scientists were generally aware that most machines would continue operating as usual through the century turnover, with the worst result being an incorrect date. This prediction withstood through to the new millennium.

There are however several other problems with date handling on machines in the world today. Some are less prevalent than others, but it is true that almost all computers suffer from one critical limitation. Most programs use Coordinated Universal Time (UTC) to work out their dates. Simply, UTC is the number of seconds elapsed since Jan 1 1970. A recent milestone was Sep 9 2001, where this value wrapped from 999'999'999 seconds to 1'000'000'000 seconds. Very few programs anywhere store time as a 9 digit number, and therefore this was not a problem.

Modern computers use a standard 4 byte integer for this second count. This is 31 bits, storing a value of 231. The remaining bit is the sign. This means that when the second count reaches 2147483647, it will wrap to -2147483648.

The precise date of this occurrence is Tue Jan 19 03:14:07 2038. At this time, a machine prone to this bug will show the time Fri Dec 13 20:45:52 1901, hence it is possible that the media will call this The Friday 13th Bug.

Re:Collective fear

[TRS80NT]

Exactly, blaine. I became interested in the problem in the early 90's, explored a lot of cooperatively hyperlinked .mil and .edu sites discussing the situation. Solutions were being kicked around, discussed, discarded and fixes phased in. By the end of the decade the popular press had gotten wind of the situation and made it the anchor story for the end of the millennium. Then lawyers and quick profit businesses jumped on board and the panic bandwagon was rolling.
All the while the fixes were slowly, calmly being instituted.