Those who think they have until the beginning of the next century to fix the year-2000
computer problem are in for a shock.
A year from tomorrow, tens of thousands of computers could skip or delete critical data
or fail to make calculations properly all because programmers long ago used the
series 9999 in computer codes to mean anything but Sept. 9, 1999.
Experts say Sept. 9, 1999, will be a real test of how many computer systems are still
vulnerable to the so-called millennium bug. It could mean bad reports and
wrong answers on everything from air-traffic control and bank balances to tax collections
and building permits.
Technology experts are even more concerned about Jan. 1, 1999, little more than 100
days away. Thats when many corporate and government computer programs begin making
one-year calculations and projections that for the first time will reach the year 2000.
Most companies started late, are moving too slow and are too optimistic to
be ready for Jan. 1, 1999, says Jim Woodward, senior vice president at Cap Gemini America,
an information-technology consulting firm. This is too big, too pervasive to get it
Computers that do everything from issuing paychecks to controlling stoplights to
targeting missiles need to be able to add and subtract dates and years.
But many old programs were written assuming the year always would begin with
19. Put simply, the year-2000 computer problem means that if an unknown number
of programs and microchips around the world arent fixed or replaced, computers that
read 00 as the year 1900, not 2000, will
fail or malfunction on Jan. 1, 2000.
The dates Jan. 1, 1999, and Sept. 9, 1999, are just two of the pre-2000 dates that may
trip up computers that arent rendered year-2000 compliant. Dates
signifying the end of a quarter, a month or a fiscal year also pose potential trouble for
specific industries, companies and government agencies.
As with the larger year-2000 problem, the question nobody can answer is exactly how big
a headache these dates will prove to be for millions of computers that we depend on for
everyday life and business.
Unlike the year-2000 bug, the Sept. 9 snag is not about computers assuming its
1900 when reading a two-digit date. It has the same root, though: Programmers failing to
anticipate the future. They designed some programs so that if someone entered a series of
nines in the place where a date goes, it meant no date was available. The program often
made special exceptions for that record. And thats exactly how an uncorrected system
would interpret data actually entered on Sept. 9, 1999.
In other instances, programmers used a series of nines to mark the end of a file. An
uncorrected system thus might skip over other valid data after reading a series of nines
meant to represent the date 9/9/99 not the end of a file. The program
cant produce the correct response.
Some programmers used nines as an expiration date for data, meaning that a year from
now, uncorrected systems could delete material that contains 9999 all
because programmers didnt think their programs would still exist next year.
The good news is that if your local governments, banks and companies already are
combing computer programs to make them ready for Jan. 1, 2000, theyre almost
certainly looking for other problem dates, industry experts say. But if they havent
begun serious work, the year-2000 problem first may be a year-1999 problem.
Top of Page | 5
Issues for 1999-2001 | Home Page
Donald Evans, director of information systems and telecommunications for Montgomery
County, says counties and cities that far behind had better focus on contingency plans,
and fix what small things they can. He and other technology experts say the
secondary benchmark dates are nowhere near as serious as Jan. 1, 2000, but
could give us a preview of what to expect.
Montgomery County computer programmers have checked for the nines problem
along with other critical dates, though Mr. Evans says they dont keep track of how
often theyve found and fixed it.
Fairfax Countys computer workers say they are replacing entire computer systems
in the public schools to make sure such dates dont become programming glitches, but
have not seen it as a major concern in fixing other government systems.
The District also is on top of the pre-2000 date traps, says D.C. chief technology
officer Suzanne Peck, although she wasnt familiar with the phenomenon until The
Washington Times asked about it. After a phone call to IBM, which the city pays $2 million
a month to exterminate its millennium bugs, she reported the computer giant has got it
covered. Both Cap Geminis Mr. Woodward and Barry Ingram, vice president and chief
technology officer for EDS, say they expect the nines fallout to be relatively
Mike Humphrey at Public Technologies Inc., which helps associations of cities and
counties with technology issues, is more concerned that the situation not turn into a case
of the boy who cried wolf:
If no significant breakdowns occur on Jan. 1 or Sept. 9 next year, some computer users
might dismiss the year-2000 issue as hype and hysteria and halt expensive repairs months
before the big problems predicted by many experts on Jan. 1, 2000.
Still, potential snags on the earlier dates have to be found and fixed. In Maryland,
Frederick County had to fix computer systems that monitor jail sentences before last July
1. The maximum sentence for those doing time in the county jail is 18 months, and the old
program made the computer read a release date of Jan. 1, 2000, as Jan. 1, 1900. Come July,
the computer would have started reporting inmates had done their time.
Capers Jones, a scientist at Software Productivity Research Inc. and one of the
foremost experts on dangerous dates for computers, uses the example of a pharmaceutical
company that made a drug with a shelf life of four years. In 1996, the company produced
batches of the drug and then, later in the production cycle, destroyed them because the
computer thought 1900 was the expiration date.
Staff writer Jeremy Redmon contributed to this article.
Top of Page | 5
Issues for 1999-2001 | Home Page