http://208.246.212.80/national/nation-19991227.htm

'Leap year' glitch lurks in shadows of 2000 bug By Joyce Howard Price THE WASHINGTON TIMES

Fears about computer glitches won't end Jan. 1, 2000, or even by the end of next month. There are also concerns about problems beginning Feb. 29, 2000, which will be the first "leap day" in a turn-of-the-century year since 1600.

Fears about computer glitches won't end Jan. 1, 2000, or even by the end of next month. There are also concerns about problems beginning Feb. 29, 2000, which will be the first "leap day" in a turn-of-the-century year since 1600. John Koskinen, chairman of the President's Council on the Year 2000, acknowledged the potential for problems caused by a leap-year bug in an interview yesterday on ABC's "This Week." He explained that, generally speaking, the first year of a new century is "not a leap year, unless it's divisible by 400." "And it turns out enough people didn't understand that, that they programmed year 2000 as a non-leap year," when, in fact, it is a leap year, said Mr. Koskinen. Although there's been a lot less publicity about the so-called "leap year" problem than the infamous bug that could bite on Jan. 1, "everyone's been testing" their computer systems for both, Mr. Koskinen said. "We will monitor whatever happens on the 29th, just the way we are monitoring what happens over the weekend of Jan. 1," he said. Jack Gribbin, spokesman for the president's council, told The Washington Times later: "We don't think it [the leap-year bug] is comparable in significance to the [year-2000] rollover. It represents another noteworthy day that could pose a challenge." But, he said, tests to date suggest only a "small incidence" of computers that won't be compliant for the leap day. He noted that federal agencies and many businesses and other organizations tested for this when they tested for the year-2000 bug. "This is more of a software issue than a hardware issue," Mr. Gribbin said. Because of that, he believes operational shutdowns would be unlikely. But other computer experts contend that some programmers overlooked the leap-day problem when they addressed the year-2000 bug. And they say this will trigger problems for some businesses for the duration of 2000. A report out of Tokyo earlier this month said the leap-year glitch could throw Japan's banking system into turmoil. Experts expressed fear that settlement programs may malfunction and trigger a chain of defaults. Computerworld magazine suggests it would be unusual if there aren't some computer problems on Feb. 29. It points out that "virtually every leap year in the computer age has had glitches," and it cited the following episodes that occurred in 1996: a) A New Zealand aluminum smelter literally had a meltdown when the computers shut off. They were not programmed to handle a 366th day. b) About 60,000 people were unable to buy Fantasy 5 lottery tickets in Arizona on Feb. 29 because the lottery-machine software did not recognize the leap day. c) Lab-equipment software used by heart surgeons at Papwoth Hospital in Britain could not function Feb. 29, so other labs had to fill in. d) A higher taxicab fare in New York went into effect March 1. But meters programmed by one company in Queens forgot about the leap day and wrongly charged the higher rate on Feb. 29. Computerworld notes that the rules for determining leap years are more complicated than the "every four years" rule taught in grade school. Years divisible by 100 are not leap years, except for those divisible by 400, which are. So, 1900 was not a leap year, but 2000 will be. The next century year after 2000 that will have Feb. 29 on the calendar will be 2400. Events in the 16th century have led to this computer-age glitch. When Pope Gregory XIII developed the Gregorian calendar, he concluded that the Earth takes slightly more than 365 days to revolve around the sun, so he added one extra day every four years to compensate. Years later, scholars determined that Pope Gregory had overcompensated for the slight irregularity. So they decided turn-of-century leap years would occur only in years divisible by 400, or every 400 years. Said Mr. Gribbin: "The use of [only] two digits to signify a year was standard practice" in the early days of computers, so there was good reason to fear that computers would think it was 1900, not 2000, when the new year rolls in. Major computer overhauls were required to prevent that. But Mr. Gribbin said there's much less reason to believe a failure to identify 2000 as a leap year was commonplace. "It's possible some programmers made the wrong judgment," he said.

-- Hokie (nn@va.com), December 27, 1999

Answers

Next time some moron says, "Well, since we have not had any real Y2K problems occur yet, and we are so close to Jan 1, 2000, it is obvious that things are going to work out just fine", REMEMBER THIS ARTICLE. It is a PERFECT example of how things were indeed going "just fine". Until a specific date and time rolls in -- then all hell breaks loose. (As I recall from reading other accounts, the New Zealand smelter plant had it's meltdown PRECISELY on January 1, 1997 at 00:00 -- it was at that precise second that the 365 versus 366 day incompatibilty caused the process control computers to go bonkers.)

-- King of Spain (madrid@aol.cum), December 27, 1999.

4 days.

Y2K CANNOT BE FIXED!

-- Jack (jsprat@eld.~net), December 27, 1999.

Sorry King of Spam, better go back to 3rd grade math. January 1, 1997 would have been the 367th day of 1996, not the 366th. If there really was a problem (this is starting to look more and more like an urban legend because no one has ever posted a verifiable, objective source for this) it would have happened at 00:00 on Dec. 31st.

-- My Full Name (My@email.address), December 27, 1999.

"Urban legend" my ass, you pollyanic piece of crap!!!!

www.house.gov/science/couffou_3-20.html

under the section "Critical Systems", sub-section "Manufacturing Process Control Systems". Moron.

-- King of Spain (madrid@aol.cum), December 27, 1999.

You mean this:

Critical Systems

Manufacturing Process Control Systems Most manufacturing plants are highly automated. A small manufacturer of industrial liquid solutions found their production line completely stopped on January 1, 1997. It was discovered that their process control systems were not designed to account for a leap year (1996) and subsequently shut down when the changed from 1996 to 1997. Before company personnel could remedy the situation, the liquid solutions that were in the process pipelines hardened and could not be removed. The company was forced to replace the process pipelines at a cost of $1 million. They were unable to manufacture products for several days,thereby, causing late deliveries to customers. In addition to the cost to repair the pipelines, the company believes they lost three new clients because their shipments were delayed.

That is interesting. I've never heard a large aluminum smelting operation called "a small manufacturer of industrial liquid solutions". That is exactly why it appears to be an urban legend -- roughly the same story appears in various places with differences in the details and no concrete evidence of anything. Why not check out the Comalco website and you will see that they set new production records the first quarter of 1997, hardly what you would expect from a "complete meltdown". The article above even makes the same mistake that you did -- even the alleged failure really was due to the system counting days and didn't know how to deal with a 366th day, the problem would have occurred on Dec. 31st, not Jan. 1st.

Keep trying, Lord of (IL)Logic

-- My Full Name (My@email.address), December 27, 1999.

You are a case study in pollyanic straw grasping. Let's see, now, MAYBE "a small manufacturer of industrial liquid solutions" ALSO ran "a large aluminum smelting operation" -- do you suppose this could POSSIBLY be?? And what is "Comalco", what possible relevance does it have to any of this? Why should we care what it's trend setting production records show??

And last but not least, you presumably have the actual computer coding in front of you, right? So YOU have determined exactly WHEN the failure would have occured, and so you find the entire account in error, right??

Gawd. As Diane would say, "Amazable"....

-- King of Spain (madrid@aol.cum), December 27, 1999.

You are a case study in pollyanic straw grasping. Let's see, now, MAYBE "a small manufacturer of industrial liquid solutions" ALSO ran "a large aluminum smelting operation" -- do you suppose this could POSSIBLY be?? And what is "Comalco", what possible relevance does it have to any of this? Why should we care what it's trend setting production records show??

And last but not least, you presumably have the actual computer coding in front of you, right? So YOU have determined exactly WHEN the failure would have occured, and so you find the entire account in error, right??

Gawd. As Diane would say, "Amazable"....

-- King of Spain (madrid@aol.cum), December 27, 1999.

What is 'amazeable' is that a butt-munch with your obvious lack of intelligence manages to live at all. Do the math asshole -- if the alleged computers were only expecting 365 days in 1996 and crapped out when faced with a 366th, then it has to happen on the 31st. If it happened on the 1st, then it was not caused in the way described.

As far as Comalco, why not do a little research. The alleged smelting operation in question has been listed in several threads as the Tiwai Point facility in New Zealand, a joint venture between Sumitomo and Comalco, Comalco being the majority holder. If you had any brains at all, you could have looked it up but it is much easier to simply swallow any story that suports your viewpoint without question.

You are the one grasping at straws. Provide one piece of objective, independent evidence to support your claim, if you can. (Try using your Webster's if 'objective' and 'independent' give you too much trouble).

-- My Full Name (My@email.address), December 27, 1999.

What a moron!!!!

1) In addition to the article posted at the start of this thread, I provided a link to congressional TESTIMONY UNDER OATH that completely supported the account of the meltdown incident. "Urban legend" indeed.

2) With no supporting anything, you try to infer that the production history of some company which may or may not be relevant is somehow germane to the incident.

3) With no supporting anything, you try to infer that working through "the math" leads you to believe that the incident should have occured a day earlier. Does the term "broken computer code" mean anything to you? Does the idea that computer code that HAS AN ERROR IN IT might in fact produce a result that "working through the math" does not support have any significance to you? Are you trying to say that this PROVES that the entire incident is a hoax, and somebody committed perjury???

Now, WHO did you say was grasping at straws??? LOL!

-- King of Spain (madrid@aol.cum), December 27, 1999.

** sigh ** Another mangled account of the Gregorian calendar change:

>When Pope Gregory XIII developed the Gregorian calendar, he concluded that the Earth takes slightly more than 365 days to revolve around the sun, so he added one extra day every four years to compensate. Years later, scholars determined that Pope Gregory had overcompensated for the slight irregularity. So they decided turn-of-century leap years would occur only in years divisible by 400, or every 400 years.

I'm not sure from the way this is presented whether it was Computerworld, Mr. Gribbin, or someone else who screwed this up, but here are corrections to errors in the above quoted set of sentences:

1) Julius Caesar (yeah, the famous Roman guy), not Pope Gregory, instituted the calendar with leap years every fourth year and no exceptions to this fourth-year rule. Thus, that version of the calendar is called the Julian calendar.

2) The "scholars" referred to in the above were _advising_ Pope Gregory, not correcting him. They determined that the _Julian_ calendar's leap-year rule overcompensated.

3) The Gregorian calendar was the _result_, not the target, of those scholarly recommendations that "turn-of-century leap years would occur only in years divisible by 400". We are still using this version of the calendar.

4) Pope Gregory accepted and implemented the scholars' recommendations. Our current version of the calendar is named after him because he got it right (enough for the next several hundred years, anyway), not because his version was the one that needed correction.

And, as I've pointed out in previous postings, the English Parliament correctly stated the Gregorian calendar leap year rules in its calendar act or 1751, including the specific listing of 2000, 2400, and 2800 as future leap years. So there's really no excuse for not knowing the leap year rules in Britain (isn't Computerworld headquartered in Britain?) or any former British colony such as the USA -- they've been plainly written out in common law for almost two-and-a-half centuries now (longer than either the Declaration of Independence or the Constitution of the United States). :-)

-- No Spam Please (nos_pam_please@hotmail.com), December 28, 1999.

All right, see if you can follow it this time. In your original response you stated:

"(As I recall from reading other accounts, the New Zealand smelter plant had it's meltdown PRECISELY on January 1, 1997 at 00:00 -- it was at that precise second that the 365 versus 366 day incompatibilty caused the process control computers to go bonkers.

This statement is absolutely incorrect! The "365 versus 366 day incompatibility" happened on Dec. 31st, just like it does every leap year -- Dec. 31st is ALWAYS the 366th day. So, if the computers locked up at 00:00 Jan. 1, then it was NOT "at the precise second that the 365 versus 366 day incompatibility occurred". I realize English must be your second language but try to keep up.

And no, I do not have the code anymore than you do. And the fact that elementary mathematics seem to befuddle you is not the reason that I said this appears to be an urban legend. Nor did I ever infer that this was proof of a hoax or that someone committed perjury. You talk about an aluminum smelter in New Zealand in your original response above and, when I question its validity, you provide a link to a nearly 3 year old document that talks about an unnamed "small manufacturer of industrial liquids" and you call this PROOF??? If she is referring to the same site, I would be interested in knowing all of the large aluminum smelting sites in New Zealand that are also small industrial liquid manufacturers. There must be hundreds!!!

I don't believe that the author committed perjury -- she merely repeated a story that she had heard second hand and obviously the facts had changed along the way. There is no reference or objective evidence for anything in her report. She even has the classic elevators to the basement listed as a "fact". Nice choice of sources there, King!

Finally, let's try the Comalco. If you don't understand what Comalco's Tiwai Point Smelting operation has to do with this discussion, then you are beyond help! That is the site of this alleged leap year problem occurred. Maybe I gave you too much credit, assuming that you had at least a grasp of rudimentary facts (who, what where, when, etc.) of the anecdotes you passed along. Or are you just a mindless putz who regurgitates whatever he hears without doing any checking at all.

The only reason I even brought up their production is that, whenever this story gets brought up, the implication is always that it cost millions of dollars to repair and they were out of productions for months before they fully recovered. The fact that they set a new production record the quarter which began on the date of this alleged 'disaster' tells anyhone with any common sense that it could not have been that big of a deal.

Now, to address your latest response specifically:

1) In addition to the article posted at the start of this thread, I provided a link to congressional TESTIMONY UNDER OATH that completely supported the account of the meltdown incident. "Urban legend" indeed.

Ohhh, I see it was "UNDER OATH". That changes everything. No one, and I mean no one, would ever lie or exaggerate or stretch the truth when they were under oath, especially not to Congress and especially not when by exaggerating the seriousness they might stand to benfit financially by selling their Y2K services. What could I have been thinking? Washington D.C. is the Pantheon of honesty and integrity!

2) With no supporting anything, you try to infer that the production history of some company which may or may not be relevant is somehow germane to the incident.

Already addressd. If you had read my previous post a little closer, you wouldn't look like such a dumb ass by asking how Comalco was relevant a second time!

3) With no supporting anything, you try to infer that working through "the math" leads you to believe that the incident should have occured a day earlier. Does the term "broken computer code" mean anything to you? Does the idea that computer code that HAS AN ERROR IN IT might in fact produce a result that "working through the math" does not support have any significance to you? Are you trying to say that this PROVES that the entire incident is a hoax, and somebody committed perjury???

Obviously, you see that you are wrong by grasping at the "code is broken" straw. Since you can't logically refute the math, jsut say that the code is 'really, really broken' and then try to change the argument by inferring that I said things that I never even implied. There is abig difference between a 'hoax' and an urban legend. A hoax is intentionally misleading, a legend is usually just the result of embellishment or misunderstanding as a story gets passed along. For the record, I believe there was a minor problem at the smelter in question since they were undergoing a major upgrade of equipment and controls. I have yet to see OBJECTIVE, INDEPENDENT (try Mr. Webster again, King) "supporting anything" (to use your words!) that it was due solely to a computer programmed to count the number of days in the year and didn't understand leap year.

As usual, this comes down to the proving a negative problem (I cannot PROVE that the alleged incident did not happen exactly as described). But, I don't have to because you have provided no proof that it did nor even a reasonable scenario that would make it sound even plausible.

Now, WHO did you say was grasping at straws??? LOL!

Yes, I am getting a rather good chuckle out of this.

-- King of Spain (madrid@aol.cum), December 27, 1999.

-- My Full Name (My@email.address), December 28, 1999.

What's a matter, King? You don't want to play anymore? You need to learn how to be a good loser. Don't worry, you'll be getting lots of practice in a few days!!

-- My Full Name (My@email.address), December 28, 1999.

"My Full Name":

Neither you nor I have first hand knowledge of what happened in this incident that occurred on or about 1/1/97. All we can do is go by the reports that are on record.

Yes, generally speaking, someone giving a report in the form of sworn testimony -- i.e., UNDER OATH -- is indeed considered more reliable than an account not under penalty of law. Certainly, this does not in any way guarantee that the account is accurate or honest, but unless we have good reason to believe otherwise, it would seem reasonable to accept it as fact. (And note that the fact that the sworn testimony is nearly 3 years old actually makes it MORE CREDIBLE, since the incident in question is just about 3 years old. Thus, the testimony was given while things were still "fresh"; and far less likely to have had the time needed to evolve into an "urban legend".)

You THINK that you have good reason to believe otherwise, because you have "done the math", and have found that by your method of calculation the meltdown incident should have occurred a full day earlier. This is a huge fallacy, as you are making the assumption that the computer code that was written -- i.e., the ERRONEOUS computer code -- correctly implemented your algorithm, and that the action of causing a meltdown was then instantaneous. Neither of us are privy to these details. All we know, based on the evidence (sworn testimony) at hand, is that due to the inability of the code to handle a leap year (1996), a meltdown occurred, even though up until it did, the process was running without any apparent problems. (Which was really THE point that I was making in my first post onto this thread.)

Having built your house of cards on this groundless assumption, you go a step further and drag in a company ("Comalco"), their production report for that year, etc. You present no evidence that this was the company involved. And even if you did, it would change nothing. It is a "red herring", so to speak.

You MAY be right, the entire incident may be fabricated or embellished out of proportion to what actually happened. People who argue that the earth is flat, or that NASA space travel is a hoax, or that the Nazi holocaust never occurred, etc., always do so in the same way: assume that enough people are lying or mistaken, assume that certain details do not jive because of a particular baseline assumption being made is violated, etc., and you can pretty much assert anything.

Which is where COMMON SENSE enters -- a characteristic that most pollies do not seem to have. Common sense leads me to believe that the incident as reported in sworn testimony is quite feasible and quite believable. The account itself seems solid enough, the credentials of the person under oath seem solid enough, etc. Nobody -- least of all, you -- has come up with anything convincing as to why it should not be believed. IT IS JUST PLAIN COMMON SENSE TO BELIEVE IT.

Noone would be trying (and failing) so hard to try to wash the incident way unless they were REALLY worried about Y2K but were not PREPARED for Y2K. As you note, in a few days we will find out just how common plant meltdowns due to bad computer code are.

I'll tell you this: I'm prepared to be wrong. Are you?

-- King of Spain (madrid@aol.cum), December 28, 1999.

Float this to the top.

With the disappearing/re-appearing forum problem, I wanted to give "My Full Name" a final chance to respond.

-- King of Spain (madrid@aol.cum), December 30, 1999.

King: Glad you responded. I responded on the backup forum but you apparently missed it. Here it is: ---------------- Remember our little discussion of the last few days regarding the "complete meltdown" of the aluminum smelter due to a leap year problem which I called an urban legend? Looks like I was right! As I stated, there was indeed a minor problem related to a leap year issue but the effects were greatly exaggerated:

The Tiwai Point New Zealand Aluminium Smelter 31 December 1996 leap year computer error

A system error occurred at the pot-cell micro-computer level due to an indices overflow on the 366th day of the year in 1996, ie just after midnight on the morning of 31 December 1996. Subsequent corruption of memory prevented the correct restarting/downloading of data from the supervisory computers, necessitating the manual resetting and reloading of each of 612 individual pot-cell micro-computers.

Because of the two-hour difference between New Zealand and Australia, staff in New Zealand were able to warn their counterparts in Australia of the problem Tiwai Point had experienced within that 2-hour time frame, enabling the Tasmanian (Australia) smelter to correct the problem in advance of midnight.

While this was a significant operating issue on that day for the Tiwai Point smelter, the system error did not result in business interruption in any sense - metal production continued despite several cells failing earlier than expected. It should be noted that cell failure is a normal event in the running of any aluminium smelter and their systems are designed to handle this eventuality without risk to people or to the production process.

Source: Year2000 New Zealand

Be sure to read that last paragraph several times since comprehension seems to be a bit of a challenge to you! "No business interruption in ANY sense!" Also, note what most people have been saying all along about process control systems -- failures are normal events and the entire system and process is designed to cope with failures "without risk to people or to the production process".

Too bad we can't access your original "factual" post that included such things as $1 million losses, complete shutdown of the process, metal hardening in the pipes resulting in massive repair work, etc.

Now, what was that you were saying about grasping at straws...

P.S. - Note the date that the problem occurred -- Dec. 31st, not Jan. 1st. I will accept your apology for the 'pollyanic piece of crap' insult when you can compose yourself!!

-- My Full Name (My@email.address), December 31, 1999.

King of Spam, do you like to mudwrestle?

-- Rich (rubeliever@webtv.net), December 31, 1999.

This article indeed brings in new info. I'm glad that no business problems were encountered, but I remind you that the basic point that I wanted to make in my first post to this thread apparently remains valid: You can have a computer process running normally, without a hint of a problem, and then have a failure occur due solely to a date related snafu. (I was motivated to point this out due to pollies that have claimed that this is simply not realistic.)

Almost any prior "Y2K like" problem that has ever occurred before can probably be shown to have caused minimal overall impact, since it generally was isolated in nature. The question is, and has always been: What will be the overall impact when NUMEROUS similar problems occur AT ROUGHLY THE SAME TIME in unison with MANY DIVERSE PROBLEMS THROUGHOUT ALL INDUSTRIES? This is the potential effect that Y2K problems have.

-- King of Spain (madrid@aol.cum), December 31, 1999.

This article indeed brings in new info. I'm glad that no business problems were encountered, but I remind you that the basic point that I wanted to make in my first post to this thread apparently remains valid: You can have a computer process running normally, without a hint of a problem, and then have a failure occur due solely to a date related snafu. (I was motivated to point this out due to pollies that have claimed that this is simply not realistic.)

Brilliant King! Did you just come up with this? Isn't a date related snafu in an otherwise normally operating system the whole point of Y2K testing and remediation? This was pretty funny until I read the next paragraph:

... The question is, and has always been: What will be the overall impact when NUMEROUS similar problems occur AT ROUGHLY THE SAME TIME in unison with MANY DIVERSE PROBLEMS THROUGHOUT ALL INDUSTRIES?

Didn't you just get done saying (in your Quit Whining thread) that it would take weeks before we knew what the real impacts were? Now, if all of these problems are going to occur in unison, throughout all industries, wouldn't that make a pretty big impact almost immediately?

-- My Full Name (My@email.address), December 31, 1999.

Yes, date testing certainly should have been a part of Y2K remediation/testing. That has nothing to do with (for the third time) the GENERAL fact that a system can SUDDENLY encounter problems due to a date related snafu. If you are trying to claim that it WON'T happen due to Y2K BECAUSE the systems have been remediated/tested, that is a different issue altogether.

No, you certainly CAN have multiple problems occur BUT not yet impacting anything. Ever hear the question, "If a tree falls in a forest and nobody is around does it make a noise?" If it's midnight on a Friday night on a holiday weekend, and your bank account gets vaporized, are you going to notice it as soon as it happens?

-- King of Spain (madrid@aol.cum), December 31, 1999.