Only 8% of Potential Disruptions To Occur on 1/1/00? : LUSENET : TimeBomb 2000 (Y2000) : One Thread

I read on some web site the other day, can't remember which, exactly, but from a source that one would assume to be knowledgeabnle, perhaps even Ed Yourdon, that only 8% of the potential disuptive effects of the Y2K problem will be experienced immediately after midnight January 1, 2000. I would have expected a that almost ALL of the disruptions would occur on or about January 1, 2000. But the gist of this statement was that we're looking at a window of woe, starging on or about April 1, 1999 and extending well into the year 2000. That is the time frame we are talking about when we speak of the Y2K bug. I'm grappling with the implications of this statement. Does it imply that one will be in a much better position by mid to late 1999 to assess what will be the probable outcome of January 1, 2000? Or is it, rather, that only another small percentage of problems are anticipated in 1999, and the great bulk of the problems are expected in the weeks and MONTHS AFTER January 1, 2000?

-- Geoffrey Smith (, January 09, 1999


"Does it imply that one will be in a much better position by mid to late 1999 to assess what will be the probable outcome of January 1, 2000?"

Yes to the above - as the year accelerates forwards we will all be watching like hawks for signs of y2k's potential impact. We will be much more informed by then, hopefully, with more detailed knowledge on compliance rates, failures, the world economy, the markets etc.

-- Andy (, January 09, 1999.

A bit more than two years ago, when the topic was just starting to heat up and embedded systems were still off the radar, the concerns focused mainly on end of month, quarter, and year processing in 2000 itself. Lookaheads were viewed as considerably less threatening.

Consider also that the vast majority of remediation programs are using techniques designed to postpone, rather than fix, this issue. I've heard nobody even mention any plans to go back later to correct this, so we can confidently expect little bombs to keep going off for the rest of our lives. The details are explored in another thread.

I believe it will be at least two years before we can consider ourselves to have weathered the worst of it (assuming we weather it that long).

-- Flint (, January 09, 1999.

Doug Carmichael believes that serious disruptions will occur throughout 1999 and 2000. (not html)

-- dave (, January 09, 1999.

And lets not forget, sometimes one needs to consider the quality in addition to quantity. Embedded chip failures will start to kick off on or about 1/1/2000, and although in a sense their failure rates are low, the potentially can pack quite a punch. (Think: electric power, water filtration systems, ...)

-- Jack (, January 09, 1999.

I don't think ANYONE can predict what will happen. 8% is as valid as someone saying frogs will take over Washington. The fact is, no one knows how many computer systems will fail at the strike of midnight and that's what makes all of this so...unknowable. What we do know is that many are awaiting April. I, myself, live in Denver and plan on transferring back to California and my family. I intend on doing that BEFORE April, since that could be Panic Day. If nothing happens, then perhaps the panic won't start til Nov or Dec. 'Course, I'm not willing to take that risk.

-- Warren (, January 10, 1999.


Although almost every news story and magazine article about Y2k repeats that the problem is that computers encountering a two-digit year of "00" may treat it as 1900 instead of 2000, there are actually many different computer problems under the "Y2k" umbrella designation. These different problems will manifest themselves at differing times, according to the nature of the problem. (What all these problems have in common is that they are date-related in some way, and triggered by some date in or near the year 2000.)

Example A: Suppose you're in a state whose government's fiscal year begins on April 1. It probably has lots of computer programs doing calculations about fiscal years, taking into account that the fiscal year runs from April through December of one calendar year, then January through March of the following calendar year.

If one of those programs cannot properly handle dates where the year number is "00", it may start causing problems in April 1999 because it is _looking ahead_ to the year 2000 in some of its operation and making mistakes because it is not properly calculating the next calendar year number.

Example B: A payroll program has to handle the differing numbers of days in each calendar month, including whether February has 28 or 29 days according to whether the year is a leap year.

Years 1700, 1800, and 1900 were not leap years. Some programmers have mistakenly thought that 2000 would also not be a leap year. But 2000 actually _will_ be a leap year. So some programs will mistakenly not account for February 29, 2000.

This 2000-not-a-leap-year bug sounds like it might be fairly trivial - just a matter of errors in printing dates, paychecks a day early or late, and so forth.

But -- and this is a true story, well documented -- at midnight of December 30, 1996, two aluminum smelters in New Zealand and Australia had their computer-controlled furnaces suddenly shut down without going through the normal procedures. They couldn't be restarted in time to prevent millions of dollars worth of damage done to the furnaces when they cooled improperly. It was determined that the reason for the shutdown was that the computer programs controlling the furnaces had not been programmed to consider 1996 as a leap year. When they tried to handle the 366th day of the year, December 31, they failed, and the result was an emergency shutdown.

Imagine that sort of thing happening in 2000. Note that the problem won't show up until the last day of the year.

[NOTE: I personally found and fixed a 2000-not-a-leap-year bug several years ago. If it had not been fixed by February 29, 2000, conceivably it could have caused problems involving millions of dollars in financial transactions.]

The 2000-not-a-leap-year bug is a member of the Y2k family.

-- No Spam Please (, January 10, 1999.

I predict 1000% of Y2K disruptions will be ocurring for the next ten years and beyond. Wow, I must be really smart... now would you like me to do some consulting work for you?

-- (@@@.@), January 10, 1999.

here is the article you are referring to:

From there you can click on the whole article by Ian Hugo from Brittain. It is indeed as you say an article worth considering. I was surprised North did not give it fuller attention.

The thrust seems to be that the majority of software problems will begin in 99, especially on April 1st. Some have interpreted this to mean that this will mean less happening on 1-1-00 but not necessarily. This article does not discuss embedded chips. I agree with Jack above. Quantitatively there may be more software problems this year but the embedded chip problem starts on the new year.

I see this 60% problem leading to quick fixes and quick testing and major screwups. I believe April 1st could be the beginning of major y2k problems, increased awareness by the masses and the end of our edge on preparing.

And remember...the 60% is spread out over 99. The 20% happens on one day. Quite devastating in my opinion. b

-- bb (b@b.b), January 10, 1999.

Geoffrey- I think the 8% failure at rollover idea comes from Gartner Group, via ZDNet:

http://www.zdnet.c om/zdy2k/1998/12/5461.html

Excellent piece. Required reading IMHO.

-- Lewis (, January 11, 1999.

Moderation questions? read the FAQ