[urb-eco] Can anyone refute this?
- "The possibility of infrastructure rupture is NEVER too remote to ignore, but
it is no more a possibility on 1/1/2000 than any other day."
This is the last 2 lines of Lee's argument. I put it here so that you may
know a little of what this discussion is about.
> I don't want to take up your time quibbling about small things.
>in the interest of a fair discussion, that should hopefully lead to abetter
>understanding, I ask that you either agree or refute the simple logicalAssumption #1 is correct. All computers will not be fixed on time.
>conclusion I sent you below. Speculation about what might or might not
>happen, doesn't interest me. But if the following is wrong, then I may be
>wasteing my time, I would hope that you would show me what I am missing.
><<>Assumption 1: All computers and embedded chips will not be fixed by
>>Assumption 2: No one can know what percent of non-compliancy it would take
>>set off some form of collapse of the infrastructure.
>>Conclusion: The possibility of infrastructure rupture is not remote enough
However, from there the logic breaks down, although I can understand why
people who aren't involved with computers might think that #2 and #3 would
There are 3 misconceptions that people have about the Y2K problem that make
it seem as if your assumptions would be logical:
1) That all computers and embedded chips are vulnerable to the Y2K bug
because they all have internal clocks, 2) that many computerized systems no
longer have manual backup procedures, and 3) that if a computer with a Y2K
problem has not been fixed, it will fail or crash altogether.
All three of the above statements are false under the circumstances we're
discussing - that is, critical infrastructure like the power and water grid,
train systems, medical equipment, communications satellites, etc.
First let's look at myth #1. It's true that all computer systems have
internal clocks, and those clocks are capable of tracking the date.
However, a programmer has to go out of his way to make a computer aware of
the date. All a computer's clock does is measure sequential time in
milliseconds. It does math based on that. For example if a pacemaker has
to give your heart a jolt of electricity every 3 seconds, it just counts out
3000 pulses of the clock, does its task, then starts again for another 3000.
It has no clue what the time or date is. The programmer would never have a
reason to give it that information.
If an application DOES have to keep track of the date, a day is likewise
however many milliseconds equal a day. At that point the computer's clock
increments the date. This is called a "Julian Day Number". Just as an
example, most personal computers use January 1, 1900 as the beginning of the
Julian calendar - day number 00000 (they decided in the case of PC's to
standardize on 5 digit Julian dates). So at the end of each 24 hours the
clock just increments another number. Under that scenario, December 31,
1999 is day number 36525, and January 1, 2000 is day number 36526. Nothing
special. Just another day. A computer may *display* a date in the format
MM/DD/YY, but in the types of applications we are talking about
(infrastructure), very few store their dates that way internally, which is
what would cause a problem on 1/1/2000. Satellites, power plants, train
systems, and the like use this Julian calendar, not the Gregorian calendar
that we are used to thinking of, which is the only type of system that would
The types of computer systems that do use Gregorian calendars are *business*
applications. Your power company's billing department might have some old
systems with Y2K problems. In that case, you might get a bill saying you
are 100 years overdue! But this is obviously an error and will not cause
system rupture - just headaches for the poor folks who have to straighten
out the billing problem. Businesses may lose money because their reporting
or billing is inaccurate, but that's hardly the end of the world.
Now let's look at myth #2. Most people think that many infrastructure
systems that are computerized have no manual backup. People like Gary North
have really worked hard to scare people by telling them things like the
trains will stop running because train systems are computerized and there
are no longer any manual switches on many lines. This is completely false.
Talk to any actual railroad line foreman and they will tell you there are
manual switches and they have to use them all the time. Nobody builds
critical systems like these without manual backup, for the simple reason
that (like I said earlier) computer systems crash *every day.* Some of the
problems with them are harder to find and fix than Y2K. Right now, I'll bet
there's at least one embedded chip or system down somewhere in your power
grid and you'll never know it. ALL critical systems have manual backup.
Again, the people who will be affected by the problem are mostly businesses
who are running non-critical systems. If somebody's online store crashes,
it might be disastrous for their business but not for the world at large.
Now we'll talk about the last myth: that "non-compliance" equals complete
failure. It doesn't. All a Y2K bug means is that the system doesn't know
the correct date. This could be a drag in the case of something like your
bank, which might calculate the interest wrong on your mortgage. But the
computer won't lose your balance or any other data. The only thing it will
lose is the ability to do date related calculations correctly. In any case,
banking systems have been compliant for a long time because they've had to
deal with loans that won't expire till after 2000 ever since 1970. Social
Security and Medicare have to deal with beneficiaries born in the 1800's, so
they've had 4 digits in their dates too.
So, to figure out whether Y2K is going to cause major infrastructure
rupture, the questions need to be asked really are:
1) What percentage of computers are running critical infrastructure?
2) Of that percentage, how many use the Gregorian date system?
3) Of that percentage, how many will fail if they don't know what day it
4) Of *that* percentage, how many do not have manual backup procedures?
Based on what I've told you, I hope you can see that the final number you
would arrive at is infinitessimally small. In fact, just as big on that day
as any other day. A Julian clock is like an odometer on your car - when it
will become inaccurate depends on when it was set, how much you drive your
car and how many digits the odometer has. Lots of Julian clocks on older
systems have already rolled over, and that can happen on any day.
Even the financial systems that some people have worried about are not
having many problems. You know, the fiscal year 2000 started on July 1 of
this year. Lots of wags predicted major losses for banks and other economic
problems on that day. Nothing happened that anybody noticed. The next day
that people worry about will be September 9th, because a lot of programmers
used to enter 9/9/99 as an indicator that a process should continue
forever - not realizing that some of their systems would still be in
operation on that day! I'll wager nothing much will happen on that day
either, at least that you or I will be able to discern. Sure, there'll be
some frantic programmers working overtime to fix it. There may be some
hassles and headaches, some lost business, some lawsuits. But Armaggedon?
The possibility of infrastructure rupture is NEVER too remote to ignore, but
it is no more a possibility on 1/1/2000 than any other day.