The Millennium Bug--the unpredictable collision of high technology and human
shortsightedness--has been largely perceived as a single event that will occur Jan. 1,
2000. On that day, countless computers and electronic devices are expected to suffer a
mental meltdown because of an obscure programming blunder in which two digits instead of
four were used to represent years.
But as programmers and engineers have begun to delve deeper into the problems of their
creations, it has become clear that the bug is not a single event but rather part of a
series of crashes that will strike for months before, and perhaps years after, that
fateful date.
Like the minor temblors that precede a great earthquake, the rumblings of the
Millennium Bug have already begun to shake the landscape, from the refusal of some
machines to accept credit cards with an expiration date of "00" to the small
group of lawsuits that has been filed against such software heavyweights as Intuit and
Symantec concerning programs that won't work after Year 2000.
In the next few months, a variety of other errors will begin to surface, gradually
enlarging the scope of the Millennium Bug from the basic "00" problem to a class
of errors that spring from a common well of technological sins: shortsightedness,
excessive frugality and ignorance.
Top of Page | Where to Get
Help | Home Page
On Aug. 22, 1999, numerous electronic positioning devices will be affected by a date
change that occurs every 20 years in the Global Positioning System satellite network. On
Sept. 9, 1999, the old-style use of strings of 9s as special program markers will rear its
head, causing software to lock into electronic dementia over whether the number is a date
or a marker.
Just two months after the turn of the millennium, programs will begin to choke once
again, this time over whether or not 2000 is a leap year. It is, but for reasons so
obscure that it could qualify as a question in "Final Jeopardy."
While none of these events will rival the potential disruptions of Jan. 1, 2000,
together they paint a pattern of blunders suggesting that the conflicts between the
unforgiving exactitude of machines and the sloppiness of what is simply known as life have
just begun.
By itself, the Year 2000, or Y2K, Bug is a historic error whose rectification will take
hundreds of billions of dollars to scan programs for any calculations that involve a date,
repair ambiguous dates in computer files and search out the billions of microprocessors
that may fail because of some date error.
Programmers in the early days of computers a few decades ago commonly shortened
four-digit years to two digits in an effort to conserve a byte or two of disk space and
memory--both precious commodities at the time but now as abundant as dirt.
Some programmers recognized that the practice eventually would lead to problems at the
turn of the millennium, when the two-digit year "00" would become ambiguous,
representing either 1900 or 2000. The ambiguity in dates is easily handled by humans, who
can exercise common sense. But for machines existing in a world of uncompromising
precision, the conflicts are enough to cause a variety of problems, from calculation
errors to outright shutdowns.
Top of Page | Where to
Get Help | Home Page
Error of Their Ways Became Mainstream
Most programmers assumed that the programs and machines they created would be updated long
before that moment. Instead, some of the old errors became accepted programming practices,
and thus found their way into much newer programs as well.
In retrospect, it is clear that the two-digit error would end up being more than a
one-day problem that would come and go on Jan. 1, 2000. For example, so much of business
relies on distant financial forecasts that the "00" error affects industries
years and, in some cases, decades before the actual turn of the millennium.
The Boeing Co., which plans the construction schedule of airplanes years in advance,
was aware of the problem in the 1980s, and has been working on a solution for years.
Modern time also is split in many different ways that make the term "turn of the
millennium" a somewhat squishy issue. Afghanistan, for example, starts its fiscal
year 2000 on March 20, 1999. And on April 1, 1999, economic heavyweights Canada, Japan and
Britain will begin their fiscal years for 2000, along with such diverse entities as New
York state, Qatar and South Africa.
Most database information is kept in calendar year form. But there are many instances,
such as forecasting and accounting, in which fiscal dates are used, leading to the same
type of errors that could occur Jan. 1, 2000.
Few programmers could have imagined the problems would have gone uncorrected for so
long. Even in the 1960s and 1970s, when many of the large mainframe database programs were
written, the pace of technological change pointed to cycles measured in months or years,
not decades.
Top of Page | Where to Get
Help | Home Page
In retrospect, the faith in lightning change was misplaced, as almost everything about
digital information points to time spans in which the words "century,"
"millennium" and even "eternal" have some potential meaning. Paintings
fade, songs are forgotten and even cities eventually decay into dust. Data, however, if
properly copied and stored, is forever. Even hardware, particularly the solid-state
variety, has a surprising longevity.
One of the classic examples of shortsightedness is the old programming tradition of
using a series of 9s or 0s as a type of program marker. Sometimes they were used to mark
the beginning and end of files; other times as markers for "no expiration date"
or an unknown date.
The reasoning was that any date with 99 or 00 was so impossibly distant that it could
be safely used as a marker. The result is that there is a group of dates in
1999--including Sept. 9 and Dec. 31--that could potentially be read as one of these old
markers.
Even if programmers and engineers had known their creations would live so long, there
is still no guarantee the problems would have been avoided. The reality is that modern
technology is so complex that the details of even the best-planned systems can be
misplaced, misinterpreted or simply forgotten.
The Global Positioning System, a network of satellites used to establish navigational
positions, was developed by the military starting in the early 1970s. The system uses a
timekeeping system that works on a 1,024-week cycle, which ends in 1999.
The length of the cycle, known as an "epoch," was kept at 1,024 weeks because
it could be transmitted in a frugal 10-bit block. One extra bit would have extended the
cycle for an additional 20 years. Two extra bits would have pushed the epoch out to 2058.
The current 1,024-week cycle will end Aug. 22, 1999, and for a period, perhaps as long
as a week, some of the satellites will be separated in time by 20 years. Many receivers
will be unaffected by the change, but some will suffer a variety of problems, from
temporary shutdowns to minor burps in service.
Most modern receivers can be easily repaired with a software update. Older receivers
will work fine after all the satellites are synchronized, according to GPS manufacturers.
Charles Trimble, the president of Trimble Navigation, one of the largest manufacturers
of GPS receivers, said the root of the problem is that many people simply forgot about
this one obscure but critical detail of the GPS network.
"It's another one of the gotchas," Trimble said. "It's part of the
complexity of the technological age. There is no way we can know everything."
Trimble said that if the government had originally cut the size of the cycle to 10
years, or even five years, there would be no problems, as engineers would have been more
aware of the rollover. But 20 years, he said, is just long enough for one generation of
designers to retire and be replaced by a new generation that hasn't even heard the term
"GPS epoch."
"By having the problem occur every 20 years, people just didn't think about
it," he said. The company has posted the necessary repairs to its products on its Web
site.
Top of Page | Where to
Get Help | Home Page
It Is, But It's Not, Then It Is Again
One of the largest aftershocks that will follow Jan. 1, 2000, involves an obscure detail
many programmers either forgot or never knew of in the first place.
As most schoolchildren know, every four years, an extra day is added to February to
make up for the slight difference between the 365.24 days of the solar year and the usual
365 days of the Gregorian calendar. If a year is evenly divisible by four, it is a leap
year.
The extra day brings the two time systems nearly in line with each other, but not
quite. To account for the remaining difference, a lesser-known second rule requires the
calendar to skip a leap year every 100 years. By convention, those non-leap years occur at
the turn of centuries, such as 1700, 1800 and 1900.
Many programmers were aware of the second rule and wrote their programs accordingly.
But, unfortunately, there is a third rule to accommodate what is now a barely perceptible
distinction between the solar year and Gregorian calendar: every four centuries, a
non-leap year becomes a leap year. In other words, 2000 is a leap year.
"A year ago, there were still people arguing about whether it was a leap
year," said Jerald Hermes, director of Y2K strategies for Micro Focus, a software
development and maintenance company focused on large mainframe computers. "There's no
confusion now. It's going to be a problem for smaller companies that have taken a
nonchalant approach to fixing it."
There is actually a fourth rule of leap years that exists to deal with the extra three
days that build up in the Gregorian calendar every 10,000 years. Astronomers have proposed
an additional rule, in which any year evenly divisible by 4,000 would not be a leap year,
but no one has been in any particular rush to decide the issue.
With enough time, even the worst programming errors are eventually healed. The trick is
trying to figure how much time is enough.
Top of Page | Where to
Get Help | Home Page
Unix Systems May Try to Live in the Past
The vast majority of programs actually do push well beyond the reasonable life span of
specific technologies.
For example, 32-bit Unix operating systems have a well-known inability to deal with
dates that exist beyond Jan. 19, 2038. Unix, an operating system used on workstations and
network servers, assigns a 32-bit block of computer memory to hold the current date, which
is calculated by counting the number of seconds from Jan. 1, 1970.
After a little more than 2 billion seconds, the memory block will roll back in time.
For a variety of reasons, many Unix systems actually go back to 1902, which represents
minus 2 billion seconds from Jan. 1, 1970.
Erik Troan, chief developer for Red Hat Software, a leading developer of Linux, a
Unix-like operating system, said the chances of 2038 causing a problem are small, because
64-bit processors and operating systems already are beginning to entrench themselves in
the market.
"Sixty-four bits literally gives you some multiple of the life of the
universe," he said. "That's pretty good. We're not going to have this problem
again."
But as the Y2K problem has shown, there is no way to be certain when it comes to
predicting the longevity of technology or the ability of humans to forget the lessons of
the past.
Programmers and engineers have been having a field day cracking jokes about the year
10000, when there will be a failure of all four-digit dates.
Hermes, of Micro Focus, said that by that time, technology could be so advanced that a
program could be created with a single swipe of a pen. But even then, he was certain that
if humans still exist, someone would forget to make the proper changes.
"No doubt about it," he said. "They'll have 8,000 years to figure it
out, and still mess up."
Top of Page | Where to Get
Help | Home Page
Y Worry
Dates to be aware of in the Year 2000 problem, commonly known as Y2K, when date
glitches may threaten computer operations.
- April 1, 1999: Start of fiscal year 2000 for Canada, Japan and the United Kingdom.
- Aug. 22, 1999: The end of the first 1,024-week cycle for the Global Positioning System
network.
- Sept. 9, 1999: A potential failure of programs in which groups of 9s or 0s were used as
special program markers. Date is 9/9/99.
- Jan. 1, 2000: The Year 2000 failure.
- Feb. 29, 2000: Failure of programs that did not count 2000 as a leap year.
- Jan. 19, 2038: The end of the 32-bit Unix time cycle. The operating system will not
accept any dates past this point.
- Jan. 1, 10000: Y10K failure. Programs that use four-digit years will fail.
Top of Page | Where to Get
Help | Home Page
Copyright 1998 Los Angeles Times. All Rights Reserved
|
