<nettime> [interdoc-y2k 243] responding to the y2k problem

[Roberto Verzola <rverzola@phil.gn.apc.org>]

 >To my knowledge, no computers have been programmed to selfdestruct
 >if they should find themselves a century ahead or behind time. Nor
 >could they if they had been, for if their reference frame is a 99
 >years, then a 99 years it is -- how could a computer possibly "know"
 >if it were a century sooner or later?! Nor could it possibly find
 >itself "ahead" or "lagging behind" -- time is a construct, and the
 >computer's time appears to be 99 years.

 >I would dearly like some explanations on this point, cos no one has
 >given me any yet. I.e., what's gonna blow up, except the West's
 >finance system?

Try finding the elapsed period between any time before the Millennium
midnight, and anytime after midnight, say 23:59:59 of 99/12/31 (31 Dec
1999) and 00:00:01 of 00/01/01 (1 Jan 2000).

The correct answer is 2 seconds, right?

However, if you only use 99 and 00 for the years, you'll get something
like minus 3 billion seconds (or minus 100 years, depending on the
unit you're using), which is a wrong answer. This is the Millennium
software bug.

Any elapsed time computations between two events separated by the
Millennium midnight, if they are based on 2-digit years, will be wrong
by the same amount.

Elapsed time is widely used in *many* other computations (in computing
salaries, interest payments, corporate income, etc.). The result of
those computations will also be wrong.

In industry, there are *millions* of instruments which measure the
rate of change of industrial variables in real-time and then
automatically actuate valves, motors, pumps, etc. This rate of change
is computed by measuring or counting the variable over a period of
time, and dividing this by the elapsed time. The results of the
calculation (example: grams per second, gallons per minute, miles per
hour, tons per day, etc.) can again be wrong if a 2-digit year figures
in the elapsed time calculations. (Elapsed time is usually measured
using a real time clock, and then subtracting the start time from the
ending time -- the bug can occur here.)

These embedded systems can be found in nuclear plants (and
weapons...), chemical plants, oil refineries, oil tankers -- almost
every plant where automation has made inroads. These systems are also
so much more difficult to debug and to test because:
- the software is often asssembly/machine language
- the software is burned in ROM (read-only memories)
- technical expertise is much more difficult to find.

Also, Most system problems are caused by a single failure. This is
easy enough to troubleshoot (not always!). If two components fail at
the same time, troubleshooting is *more* difficult (if you replace the
suspected defective component with a new one and the system still
refuses to work, you will probably return the old component and look
for the problem elsewhere). Troubleshooting multiple simultaneous
failures will be *very difficult*.

On the financial side, it is easier to understand the experts'
concerns if you forget about Y2K first, and just consider what critics
of the global financial system have been warning for years: that the
system is basically flawed and the bubble can burst anytime. The basic
flaw is that banks and other financial institutions simply create more
and more money through lending and other mechanisms. So, there are too
many dollars (and other financial instruments) for the real goods and
services available. The typical figures cited are $20-$50 paper money
(and money-equivalents) for every dollar of real goods and services,
and increasing. This casino economy is growing much faster than the
real productive economy, and the whole system is built on this deck of
cards. (It is like having 20-50 people, and only one chair...). People
go along with the game, because everybody else seems to be doing it.
All it needs is a major loss of confidence in the system, and
everybody will try to convert their paper instruments into real goods
and services.

Enter Y2K: because it will hit all financial centers at the same time,
it can trigger this major loss of confidence.

Let's consider that again: there's a threat of disruption at the
production level (real goods and services), and another threat at the
financial level (money instruments). That makes it worse, because they
can mutually reinforce each other (ie, a financial problem making a
production problem worse, which then causes more financial problems,
etc.)


Roberto Verzola
---
#  distributed via nettime-l : no commercial use without permission
#  <nettime> is a closed moderated mailinglist for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: majordomo@desk.nl and "info nettime-l" in the msg body
#  URL: http://www.desk.nl/~nettime/  contact: nettime-owner@desk.nl