Slashdot Mirror


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?"

10 of 625 comments (clear)

  1. 2038bug.com mirror by Esine · · Score: 5, Informative

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

  2. Re:Collective fear by blane.bramble · · Score: 5, Informative

    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.

  3. Perl Script by derphilipp · · Score: 5, Informative
    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/ )
    --
    Spelling mistakes: My is english spoken not tongue of mother.
  4. Re:Mirror? by rtt · · Score: 5, Informative
    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.
  5. Re:Collective fear by TRS80NT · · Score: 5, Informative

    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.

    --
    Lorem ipsum dolor sit amet.
  6. A bit of both by finkployd · · Score: 3, Informative

    At the time I was a mainframe operator with Penn State (I'm still with them, just in a much less annoying job), and I remember we had a ton of things that needed fixing. Even so, there were some fairly significant problems that popped up on new year's day that had not been caught. If I remember correctly, the program that validated rsa secureIDs failed amoung some other less serious snafus.

    I imagine most places when through something similar, a few years of hunting and fixing and then dealing with some small problems that they missed after the fact.

    However, I notice that civilization did not collapse. There was no "fight club" style destruction of everyone's credit rating or a total collapse of the money system, planes did not fall out of the sky, nukes did not sporatically go off, etc. Maybe that COULD have happened but remember people began seriously talking about this problem around 1996 (at least the media began picking it up then) so there was plenty of time to fix stuff.

    Many people found great deals on generators and survival gear (food, etc) the following year on ebay :) I know that was a great time for search and rescue teams to pick up cheap gear.

    Finkployd

  7. What he said. by igorthefiend · · Score: 4, Informative

    I also worked for a bank in the UK doing admin work on their Y2K project and there was *huge* amounts of planning went into it and a surprising amount of non-compliant systems and software.

  8. Re:Mirror? by adam+mcmaster · · Score: 3, Informative

    It's signed because it is necessary to deal with dates before 1970.

  9. Re:damn right! was: [Re:Collective fear] by lars_stefan_axelsson · · Score: 4, Informative
    Also it should be remembered that there was a second problem in 2000, because of the 29th april (in 2000 there was no april 29th despite it's devidable by 4, because its also devidable by 100, or something alike).

    What? :-) Look, there's always an April 29th, the leap day being added always to February. And the year 2000 was a leap year, though many thought it so for the wrong reason. The rule is: if year is evenly divisible by 4 if not divisible by 100 unless divisible by 400. Which makes year 2000 a very special leap year as it is indeed divisible by 400.

    --
    Stefan Axelsson
  10. Re:Economics 101 by mankey+wanker · · Score: 3, Informative

    Exactly.

    The wiki article people keep pointing to also makes connections to outsourcing and a whole host of related issues that relate to bogus ideas of a free market. Clue to all: free markets are a myth sold to you to make someone's subsidy more palatable. So yes, the existence of free markets is a bold lie.

    Can anyone show me a free market anywhere on earth?

    Not in theory, mind you - where a lot of you libertarian/republican eggheads live - but in REALITY. Show me a real free market - where people live and die by the price of goods and services.

    The moment any market is fed a subsidy by the government, it is not a free market - the system will have been gamed for the benefit of a few against the many. But - and this a BIG BUT - all countries have gamed their systems exactly this way and supposedly for the benefit of their people. And when such gamed systems work for large populations, I don't really have a problem with it. Example: I like throwing money at farmers (sadly, usually republican and pyscho Xtian assholes) because I think it is in the interest of national security to have an independent food supply - in my example the farmers gain a monetary benefit, while the rest of us gain something a little less tangible in the way of national security.

    It is when the numbers of people benefitted by such a gamed system become so few that we may call this "looting" instead. I don't know that many of us are benefitted by the oil wars we fight such that the same or greater benefits could not be derived from some other energy source which might also have hidden benefits for the environment if they are cleaner energy sources.

    So yeah, Bastiat is great. Really. But he also assumes facts not in evidence. And most of us have to live in the really real world.