1/1/00: Not Our Only Date With Destiny
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.
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.
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.
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.
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.
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.”
(BEGIN TEXT OF INFOBOX / INFOGRAPHIC)
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.
