EDITORIAL. Egged on by a media frenzy of gloom-and-doom coverage of the so-called "millenium bug," well-respected economists are forecasting a global financial meltdown, untold numbers of people are stockpiling cash, food and ammunition, and opportunistic businessmen are making small fortunes by pandering to public panic about Y2K. To which AVweb's Editor-In-Chief Mike Busch says "get real!" and offers some solid reasons why January 1, 2000 is unlikely to be much different from any other New Year's Day.
December 10, 1999
folks. This nonsense has gone far enough.
It's one thing when a handful of self-appointed Y2K consultants and gurus hang out
their shingles and their web sites to take advantage of the gullible and panic-prone. Or
when a few thousand survivalist whackos announce plans to spend their 1999 Christmas
vacations fleeing from civilization and holing up in the desert with stockpiles of cash,
food, and ammunition. This is all in the grand American tradition of laissez-faire
capitalism and individual freedom.
But, when Newsweek publishes dire predictions of
financial institutions collapsing, planes falling out of the sky, elevators stopping, and
cars not starting as their embedded microchips go bezerk on January 1st, 2000, and when
Mike Wallace and Dan Rather start using the power of network television to persuade the
populace that Y2K will bring TEOTWAWKI (the end of the world as we know it), I start
And when prophet-of-doom Dr. Edward Yardeni, chief economist of Deutsche Morgan
Grenfell, estimates the probability of a deep global recession in 2000-2001 as a result of
Y2K problems at 70%, I start to worry that such high-profile doomsday predictions may
freak out investors enough to become a self-fulfilling prophecy and cause a whole lot more
damage than anything that the so-called "millennium bug" itself could wreak.
Which, as I hope to demonstrate to you, isn't all that much.
Before co-founding AVweb in 1995, I had a 30-year career in the computer
software business. I designed, developed and managed the development of operating systems,
networking, and financial applications for Fortune 500 companies. I spent three years
designing and developing credit card authorization systems for Visa International. In
short, I've been on the inside of this Y2K stuff, and it sure looks to me like the problem
is being vastly overblown. Here's why.
Y2K Has Been With Us For Years
The high prophets of Y2K and their bamboozled dupes in
the mass media paint a picture of global computer meltdown in the wee hours of January 1,
2000. The biggest flaw in this millennium apocalypse scenario is the fact that dates in the
year 2000 are nothing new to our computer systems. They've been dealing with such dates
Financial systems have been coping with 2000-series dates since the 1970s in the
processing of fixed obligations (such as government and corporate bonds) with 30-year
maturities. Medical and insurance systems have had to deal with pre-1900 birthdates, which
are just as vulnerable to the "two-digit rollover problem" as post-1999 dates
are. When I was doing software work for Visa International between 1993 and 1995, Y2K
compliance was the law of the land because everyone knew that credit card expiration dates
in the year 2000 would be upon us years before Y2K itself.
Indeed, there have already been a handful of high-profile embarrassments resulting from
Y2K-related bugs, mostly having to do with time-interval calculations that involve
subtracting one date from another. In late 1997, a computer system at the Marks &
Spencer department store in London ordered tons of perfectly good food destroyed in the
process of doing a long-term forecast when an application program interpreted some
expiration dates as 1902 instead of 2002. Instead of four more years of shelf life, the
program calculated that this food was 96 years old and ordered it destroyed. A similar
problem happened to a U.S. manufacturer of freeze-dried food.
The point is that Y2K-related software problems are not going to emerge all at once on
New Years Day. The ambiguity of a two-digit year doesn't kick in suddenly with one tick of
the clock, as the doomsayers would have you believe. Most of these problems have already
shown their ugly faces, and been fixed or worked around. More will do so as Y2K
approaches. They'll be annoying, cause embarrassment, and maybe even cause some folks to
get fired. But, "the world as we know it" will hardly notice.
Most Embedded Microchips Don't Care What Year It Is
Let's put an end to this "embedded microchip" scare once in for all. It's
certainly true that an increasing number of appliances and vehicles are controlled by
embedded microprocessors. But your coffee maker, microwave, dishwasher, television and
automobile simply don't care what day it is, much less what year it is. (Think about it.
Why would they care?)
The only common household appliance that cares about dates is your VCR. If you have an
old one, it might not handle programmed recording correctly after Y2K. If you're really
worried about this, just set your VCR clock to January 31, 1999 and then watch what
happens. Even if you're affected by this problem, you can probably survive somehow.
Besides, that old VCR probably needed to be replaced anyway.
Hardly any industrial microcontrollers care about the date, either. Y2K doomsayers
paint a vivid picture of elevators grinding to a halt (or going bezerk) at the stroke of
midnight on January 1, 2000, but a spokesman for Otis Elevator says this is absolute
Most Systems Won't Even Be Affected By Y2K At All
Most software systems in current use including
virtually all PCs and workstations, network servers, and the machines that route and
switch data over the backbone of the global Internet won't be affected by Y2K because
they handle times and dates in a fashion that simply doesn't care what year it is.
Take Unix, for example, which is the operating system that runs most Internet servers
and routers as well as most engineering workstations. Unix stores dates and times as a
32-bit signed integer that denotes the number of seconds that have elapsed since midnight
UTC on January 1, 1970. Since 32 bits is sufficient to encode integers from -2,147,483,648
to +2,147,483,647, Unix dates will not run into a rollover problem until January 18, 2037
(which is 2,147,483,647 seconds after January 1, 1970). January 1, 2000, is a totally
uninteresting date so far as Unix is concerned.
Other modern operating systems use similar schemes. If you're running DOS, Windows 3.1,
or Windows 95, the operating system date encoding will work fine until the year 2018 (at
which point hopefully nobody will still be running these operating systems). Windows 98
and Windows NT can deal with 21st century dates without heartburn.
If you're running an old 68000-based Macintosh, your dates won't roll over until the
year 2040. New PowerPC-based Macs have dates valid through the year 29,940 AD, which
should certainly be ample for anything you have in mind (unless perhaps you're a
The Global Positioning System is subject to a more obscure problem that is caused by
data format that is transmitted by the satellites. Time is expressed by the satellite as
the number of weeks since midnight UTC on January 6, 1980 ("GPS Week") plus the
number of seconds into the week. These two values are transmitted as binary integers from
the satellites and converted into conventional date (month/day/year) or day of year by the
GPS receiver for display to humans. Because the GPS Week number is transmitted as a 10-bit
binary integer, it can only count from zero to 1,023. GPS Week 1,023 will end at midnight
UTC on August 22, 1999. At that moment, GPS Week number will go to zero and start the
count over. Some older GPS receivers may have difficulty displaying the date properly
after that, but they should continue to navigate fine.
Most Vital Systems Are Fixed Already
In testimony before Congress on October 29, 1998, FAA Administrator
Jane Garvey stated that the FAA had completed Y2K-related assessment of all computer
systems and renovation of 99% of all "required" systems. She further stated that
while plans called for complete replacement of the ATC HOST computer systems that run the
ARTCCs by the end of 1999, the agency had completed software renovations of the existing
HOST system in July, 1998, just in case the upgrade to the new system winds up hitting a
snag. She stated that all FAA systems would be completed with end-to-end tests conducted
at the FAA Technical Center in Atlantic City and at the Denver ARTCC, and be fully
certified as Y2K-compliant by the end of June, 1999. Raymond Long, FAA's director of
airway services and its point man for Y2K issues, also says he's quite confident that ATC
will carry on as usual on January 1, 2000.
government agencies appear to be in equally good shape. The Nuclear Regulatory Commission,
for example, identified seven mission-critical computer systems with potential Y2K
problems. Four have been repaired or replaced already, and the other three are on-schedule
to be fixed by March, 1999.
The Pentagon has identified more than 2,500 mission-critical systems. (They take
themselves sooo seriously!) But Deputy Defense Secretary John Hamre has testified that 95%
of them will be fixed by the end of 1998, and that the remaining 5% will be fixed or
replaced in the first half of 1999.
What about Wall Street? Nick Magri, Y2K coordinator for Security
Industries Automation Corporation which oversees technology for the NYSE and ASE, says the
stock exchanges and its member firms will be ready for Y2K by the end of 1998, giving them
all of 1999 to test and retest everything. Bob Lynne of Bank of America, largest bank in
the U.S., says BofA will also have all of its systems Y2K-ready by the end of 1998, and
anticipates no problems, not even recalcitrant ATMs.
Most Remaining Y2K Bugs Won't Matter
There's no question that some Y2K problems will show
up after the witching hour on New Years Day of the year 2000, but the vast majority of
them will simply be annoying, not crippling. A classic example is your old roll-fed fax
machine that doesn't know how to deal with the date rollover properly. The result is that
header lines on the faxes it sends in January, 2000, will contain a funny-looking date.
The machine might require a chip change or board swap, or you might even want to replace
it with a modern plain-paper model. But until you do, you'll still be able to send and
receive faxes, so it won't exactly grind your life to a screeching halt.
A lot of Y2K problems will be like that: annoying but not fatal.
What about the often-cited claim that the computers controlling the nation's electric
power grid will go nuts on January 1, 2000? Doesn't pass the smell test, says the Y2K guru
for Pacific Gas & Electric, one of the largest electric utilities in the country.
According to PG&E, any unresolved Y2K problems might affect billing systems,
regulatory compliance and maintenance, but no impact is expected on the actual
distribution of power. Most power is routed manually, they explain, and automatic controls
operate on the basis of load, not dates.
Most Y2K problems can be worked around easily until they're properly fixed. For
instance, date fields that accommodate only two-digit years will ultimately have to be
expanded to four-digit representation. But in the meantime, a popular quick work-around is
simply to establish a "pivot year" to properly calculate the century part of a
two-digit year. For example if 40 were used as the pivot year, then a number less than 40
would be interpreted to mean a year in the 2000s, while a number of 40 or greater would be
interpreted to mean a year in the 1900s. For the majority of date-sensitive applications
in which valid dates can be assumed to fall within some 100-year range, this
"hack" works fine until a more elegant solution can be implemented.
Even if some crippling Y2K glitch were to make it through compliance testing somehow,
and then suddenly show up on millennium morn, so what? We deal with computer failures all
the time. Every critical computer system has backups and fallback procedures in place to
ensure that life goes on even if the computer goes down. So long as these failures are
isolated exceptions rather than the general rule, they'll be nothing that can't be
handled. And if you've read this far and still believe that a massive computer meltdown
will occur at the stroke of midnight, then I guess maybe you better pack up your cash,
food and ammo and head for the hills.
Aviation Will Be Affected Only Minimally
We in aviation probably have less cause for concern than most
industries. First, as I've pointed out, the industry is in darn good shape Y2K-wise.
Second, we probably have more backup systems and manual reversion procedures than anybody
else. Both pilots and controllers tend to be very current on these procedures pilots
because they're required to go through frequent recurrent training with emphasis on
simulated emergencies, and controllers because they deal with real computer failures so
More importantly, lift is what keeps planes aloft, not computers. I suppose one could
argue that certain embedded computers (notably FADECs and fly-by-wire control systems) do
keep planes up, but those computers could care less about dates, not to mention that
they've been stress-tested up the wazoo.
Computers don't keep planes from colliding, either. Pilots do. Just ask any pilot who
was flying in Northern California on Wednesday morning, August 9, 1995, when Oakland Center experienced a total
blackout that took out all radar and radio communications for 45 minutes. There were
no midairs or even NMACs. Nobody freaked out in the cockpit (although I understand some
well-chosen words were being uttered on the ground). Center frequencies were magically
transformed into CTAFs as pilots started chatting among themselves, trying to figure out
what the heck was going on. Flight crews discovered that they could actually fly without
clearances, and that airspeed and Bernoulli continued to do their things even without help
from the ground. Pilots looked out the windows a bit more intensely than usual, dusted off
their NORDO procedures, and occasionally bent some FARs. In the end, everyone got where
they were going, no metal was bent, and nobody got violated. Imagine that!
The Bottom Line of Y2K
My favorite summary of the Y2K problem was one I saw posted to a newsgroup by Martin
Y2K won't be a widespread system breakdown. Most systems won't be affected by it at
all. Most systems which are affected by it will already have been fixed. Most systems
which will not have been fixed will be easily remedied with an upgrade or work-around. A
few systems will create isolated havoc. Some bills will be mislabeled, some databases will
be corrupted, some servers will go down. But no planes will crash, no pacemakers will
stop ticking, no power grids will shut down, no markets will cease to function. The Earth
will turn, and the Sun will rise. We simply haven't turned control of the world over to
computers so thoroughly yet. We know them too well.
Despite all this, however, the ultimate Y2K irony is that the
doomsayers may wind up having the last laugh after all. If the media continues to pander
to public panic, mass psychology alone could lead to an economic catastrophe at the turn
of the century. The U.S. stock market is frothy, with individual investors (who tend to be
nervous anyway) heavily invested in equities. The sharp correction in the summer of 1998,
apparently in reaction to economic problems in Russia whose actual effect on the world
economy was barely at the noise level, demonstrates vividly how little loss of confidence
it takes for the stock market to crater. Imagine what could happen, then, if a significant
percentage of investors actually believe the millennium apocalypse scenario. In the words
of noted sci-fi author and futurist Jerry Pournelle:
The situation is serious, but it will not be grave unless we make it so. Widespread
sales of stocks, withdrawal of money from savings and the exaggerated hoarding of food,
fuel and inventories can transform the Year 2000 bug into a major disaster. ... Franklin
Delano Roosevelt once said the only thing we have to fear is fear itself. That is the best
mantra for considering the Year 2000 problem.