Why Y2K Won't Die

Glitch Watch: The Millennium Bug didn't cause the digital apocalypse many feared. But there still may be big headaches to come.

By Jared Sandberg Newsweek, January 10, 2000

So it wasn't the end of the world. The specter of a worldwide digital meltdown began to evaporate as the new millennium dawned around the globe Friday night, leaving billions of people united in a collective shrug. So far, even those who weren't fearing the worst seemed disappointed that the bug had no bite. But to those still hunkered down in their bunkers, glumly contemplating a lifetime stockpile of lentils, many computer experts hold out at least a tiny glimmer of despair: the real effects of the Y2K Bug may not be felt for days, weeksor even until the year 2001. So don't break open the bottled water just yet.

To be sure, the most spectacular of the predicted disastersranging from elevators that refuse to budge from the lobby, to malfunctioning air-traffic-control systems, all the way to the unintended launch of a nuclear missilefailed to materialize. Essential services were maintained throughout the developedand even the developingworld, as far as anyone could tell in the first hours of the new year. But other, subtler flaws may yet lurk in the interstices of banks, insurance companies, utilities, transportation services and government agencies. Some glitches were expected to start showing up this week, as business as usual resumed around the world; others may become apparent only as thecalendar progresses through a year's worth of billing cycles, interest periods and payment deadlines. Some of the relief that people felt on hearing a dial tone Saturday morning will undoubtedly dissipate if they get a bill for a hundred years' worth of phone service. "What you might get over a period of days or weeks is some degradation of quality," says Bruce McConnell, director of the International Y2K Cooperation Center. "It's going to gum up the works with annoying inconveniences."

A minority of experts thought that the dangers went beyond inconvenience. Ed Yardeni, chief economist at Deutsche Morgan Grenfell and a leading Y2K bear, warned about the possibility of a recession if computer glitches in foreign countries held up imports of raw materials or other goods. "Nobody really knows where the weak links are," Yardeni said last week. "But we're all going to find out together." At a mostly upbeat New Year's Day press briefing, John A. Koskinen, Washington's chief Y2k troubleshooter, said that among the five leading oil exporters to the United States, Canada and Mexico seemed secure. That left Nigeria, Venezuela and Saudi Arabia. "Are we satisfied that all of those other countries are now out of the woods?" Koskinen said. "The answer is no."

In general, small businesses, with fewer resources, are more at risk from computer screwups than giant corporations. Most people, of course, will survive a meltdown of their dry cleaners' data-processing software; unfortunately, though, most health-care providers are small businesses, as these things are reckoned. Chronically strapped for cash, the industry was among the last to tackle Y2K problems. Even before the end of last year, 10 percent of 2,000 health-care companies surveyed said they had experienced Y2K-related failures. Without centralized coordination like that in banking, there's little sense of how well the health-care industry has prepared. Some experts also fret that it remains vulnerable to the supply-chain problem. "There are a lot of steps in getting something from the rain forest into somebody's bloodstream," says Joel Ackerman, executive director of Rx2000, an information clearinghouse for the health-care industry. Any bumps along the way, he says, and we may not know until shortages show up in the second half of the year.

And even as the world awaits problems caused by Y2K bugs that went unfixed, it will confront a whole new category of problems resulting from programs that were fixed. "For every thousand changes you make to a computer system, you get eight new problems," says Peter de Jager, a prominent Canadian consultant who was one of the first to sound the Y2K alarm. "If every company and government agency has just a few problems, that still means millions of problems. The notion that all the work ends Jan. 1 is bogus." Newly written computer code is only as good as the procedures for testing it; in the wrong place, one untested line of code can have a ripple effect, not just in the program that contains it, but in all the programs that interact with it.

De Jager's comments, as it happens, were meant to reassure programmers who shared in the largesse of the $500 billion Y2K-repair industry and may now be worrying about where their next bag of Doritos is to come from. Luckily for them, the vast worldwide effort to keep computers on track past the end of 1999 meant that a lot of other important programming work got shelved over the last year or two. Innovations such as "decimalization" of the stock exchangesquoting prices in dollars and cents, rather than fractionswill keep programmers busy, and computer users on the alert for bugs, for years to come.

In fact, the next big test for computers will come in just two months, on Feb. 29, 2000a date that many programs, alas, may not know exists. This so-called leap-year bug results from a peculiarity of the Gregorian calendar, which inserts an extra day at the end of February every four years, omits it on years that end a century, but puts it back in when the year is divisible by 400. Programmers who knew the secondof these rules but not the third would have instructed their computers, erroneously, that 2000 is not a leap year. This could result in all kinds of problems if the computer happens to be, say, keeping track of an oil tanker expected to arrive in port on the day after Feb. 28. "We worked with 300 companies, and every single company had some leap-year problems," says Nigel Martin-Jones, executive vice president of the high-tech consulting firm Data Dimensions.

No one is making the same kinds of apocalyptic predictions about Feb. 29 that were bandied about in the weeks leading up to Jan. 1. But anyone still holed up with his diesel generator this week might just want to keep his tank full for another couple of months.

With David A. Kaplan

) 2000 Newsweek, Inc.

-- Vern (bacon17@ibm.net), January 04, 2000

Answers

The 1 January 2000 date was a breeze but 29 February 2000 is going to be a hurricane? Dave has got to be kidding. Is there any candidate date for *worst* day other than 1 Jan or the succeeding days on which businesses get started? With every passing day there is less and less software comparing dates before and after 1 January. Even the renouned Dale Way (who?) thought that failures would be symmetric about the One True Date.

    --bks

p.s. Could you please try to substantiate your candidate dates?

-- Bradley K. Sherman (bks@netcom.com), January 04, 2000.

Nothing of any consequence is going to happen with the embeds on Feb 29 for the same reason it didn't happen on Jan 1. 99% of the embeds don't track dates, the track elapsed time with counters. Now business systems and their databases are a *very* different matter.

I think what I posted in the following thread is what happened on Jan 1 and will happen on Feb 29.

Why nothing was ever going to happen with the embeds

----- EXERPTS FROM ABOVE FOLLOW-----

After the rollover I put my brain in gear, rather than relying on the "experts" as I have done to now about what goes in the embeds. I'm not a hardware guy, but I went back and thought about my only hardware project from 20 years ago in university (back when memory was expensive).

Any thing that is in hardware that deals in time is going to use counters to determine when time has elapsed. They are not going to use dates because you have to use more memory to store it and then convert it to a number to do the calculations and then more memory to convert the number back to a date. So they'll count seconds or days. The point of storing a date calculation is know when a certain amount of time has passed. If you use counters (even thousands of seconds for many days) it is the simplest, cheapest, and bug free way to do that - regardless of date. Now some of the more fancy hardware that is newer may have some date functions for things like maintenance (since memory is not a problem now) that has been arbitrarily decided to be done at month ends rather than on a fixed interval, but my guess are those are very few and far between.

Yourdon, I'm surprised you fell for this in such a grand way, you're supposed to be one the "experts" who investigated all this. Why Mr. CEO said all his teams were being sent home was because his clients along with all the other companies with embeds found out the above and realized that the "consultants" were swindling them by just investigating and investigating and investigating but actually doing very little else. I'm willing to bet that 99.999% of all embeds are like what I describe above. That's why the world could tollerate a 0.001% hiccup in the number of embeds out there and not blink at all.

I'm willing to bet if you turn on 99.999% of the systems with embeds there is no place to enter a date or even set one - after all I don't see every one of these systems with a keypad or keyboard to enter a date if the current date is incorrect. These systems are black boxes like your modem. Yes they track time (with a counter) not by knowing what day of the year it is. They don't care about dates they care about durations of time and days passing.

-- Interested Spectator (is@the_ring.side), January 04, 2000.

The 2/29/00 date is, if anything, even sillier than the 9/9/99 scare. For a programmer to screw this one up, he or she has to (a) be clever enough to remember that you don't do leap years on '00 years, but (b) not be clever enough to remember that you DO do leap years on '00 years divisible by 400. Stupid systems are immune; so are smart ones. In years of studying, teaching and practicing programming, I have never seen an algorithm that would have cratered on 2/29/00. There's probably one or two out there, somewhere. But not enough to matter.

-- Craig Kenneth Bryant (ckbryant@mindspring.com), January 04, 2000.

Craig:

My thoughts exactly. Let me see now, the bozo programmers think every year divisible by 4 is a leap year so 2000 is a leap year ergo no problem. The smart programmers know better ergo no problem. Now if this was 1900 or 2100 different story. Guess its y2k luck now that's saving the day. Before that it was the y2k hoax. Before that it was the hard y2k work. Before that it was ...

-- Interested Spectator (is@the_ring.side), January 05, 2000.

Craig, Interested,

While I agree that 2000-2-29 bugs probably won't be as frequent or prominent as 2000-1-1 bugs, I wish to share a personal experience with one.

About ten years ago, while scanning a day-of-week calculation subroutine for some reason, I noticed that it contained the Gregorian 100-year exception rule but not the 400-year exception rule. That is, it treated all years divisible by 100 as non-leap years, and would have produced off-by-one incorrect results for all dates after Feb. 28, 2000.

Craig, you opined, "For a programmer to screw this one up, he or she has to (a) be clever enough to remember that you don't do leap years on '00 years, but (b) not be clever enough to remember that you DO do leap years on '00 years divisible by 400." Perhaps you might be interested in what I found out when I discussed the error with the author of the subroutine.

The author told me that he had learned about the 100-year rule from his grandmother when she was talking about her life in 1900. She hadn't mentioned the 400-year rule, and he hadn't learned it anywhere else either.

It seems to me that this sort of incomplete transmission of the calendar rules probably happened in quite a few cases, and it's not so much a matter of "stupid" versus "smart" or "clever".

Also, you may remember that there was an expensive aluminum smelter shutdown in New Zealand on December 31, 1996 because a computer program did not properly handle the 366th day of _that_ leap year.

-- No Spam Please (nos_pam_please@hotmail.com), January 05, 2000.