Could it be that the 19100 is a legitimate date and that's why no crashes?

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

A point was made that the date rolling over from 1999 to 19100 is a legitimate date. Could this be the reason why we have not seen the crashes we expected? Are there any programmers out there who might know the answer to this? Thanks.

-- Kim Scaramastro (kim@antipas.org), January 02, 2000

Answers

Yes, it's all a big sham. The biggest Y2k sham of all is that there is no Y2k, we've all been teleported to Y19k100!

-- (foo@bar.com), January 02, 2000.

Why computers did not crash!

The Computer programmers told us that on January 1st the computer date would go back to 1900 and that would confuse the computer and cause the systems to crash. They were wrong.

In Russia where they did not do any repairs, electricity stayed up. Why?.... Simple. Two days ago the date was 1999. The computer thinks today is 19100. What is the number that comes after 99? It is 100. Next year the date will be 19101. We may see that date on statements from businesses, but who cares? We know that is means 2000.

I checked several news websites and they all show the date as 19100. The programmers were wrong and I'm glad! Now we can go on with life as we were acustomed to. YIPPEEEEEEE!!!

HAPPY NEW YEAR "19100"!!!!

-- bbb (bbb@bbb.com), January 02, 2000.


Damn, you're right! If the date was stored as two separate byte components, and the year field incremented without properly doing the modulo 99 arithmetic for the carry, 19100 might well be a valid way of expressing 2000 for that purpose - to a computer of course. Huh - I never thought of it that way before - at first glance most of the arithmetic would work just fine, since 1900 plus 100 is 2000, which is the way it would be done if you stored the date in two byte- fields. Wild!

-- Paul Davis (davisp1953@yahoo.com), January 03, 2000.

LOL!!!! If this really turns out to be the answer, then the universe truly does have a sense of humor.

-- Bokonon (bok0non@my-Deja.com), January 03, 2000.

Sorry folks, that might possibly work for the embeded scenario...but financial sector and all others will be toast. 19100-1999= Yes I'm rich!!!!!!!!!!!!!!!!!!!!!!!!!!

-- yes (newrichkidonthe@block.com), January 03, 2000.


I don't think that the prevalence of "19100" by itself explains a lack of truly newsworthy Y2K problems. However, it is one example of a surprisingly common phenomenea--that program logic which, on its surface, is obviously wrong, and which surely was not intended to work as it does by the original programmer, turns out through some convoluted comedy of errors to do the job. This, plus the prevalence of dead code, plus humans already being experienced in working around unreliable computers, plus code that does the same thing several times until it gets it right, plus lots of last-minute programming work the past few weeks, helps explains why code that seemingly still had lots of Y2K problems last week will more-or-less work this coming week.

Actually, as someone who was a Y2K super-optimist, there have been more problems than I expected. For example, when I used my credit union ATM card at my credit union's ATM at 5PM on 1/1, I was told that my card, which by the way has no dates on it, was expired. This almost surely was due to a Y2K bug, but isn't something that is likely to be reported in the media because the problem is surely fixed by now, and few organizations unnecessarily publicize temporary failures. By going to press conferences instead of searching out Y2K glitches on their own, the press is undoubtedly missing a lot. But people are remarkably adept at managing with buggy software, so the press will be right in reporting that Y2K problems are livable. For example: Y2K or not, I, like, I think, everyone, often finds ATM machines to be inoperable/out of money/down, so I wouldn't ever wait to go to one until I'm down to my last dollar. I was sure until Saturday that ATM's wouldn't have Y2K problems, but when I was proved wrong, I wasn't much inconvenienced. Another example of human resilance in these matters: Tomorrow, many call-center employees will see obviously wrong dates on their screens. But, in most cases, the human users will be able to discern the correct date from context, or because, as with 19100, it's obvious. In cases where the correct data isn't obvious, programmers will probably have fixes ready in a few hours, or even a few minutes. They won't be notifying the press, and really there won't have been any need to do so.

By the way, there also were a lot of unreported year 1999 problems. Whether there will, in the end, have been more year 2000 bugs than year 1999 bugs is going to be a surprisingly difficult question to answer. Of course it already seems like there are more year 2000 problems, but this could be because we are more geared up to noticing them.

Steve Eisenberg

-- Steven Eisenberg (steveei@my-deja.com), January 03, 2000.


Hi Steve,

As a Y2K super-pessimist, I'm suprised that we are seeing "this many" 19100 problems. This is one of many possible "options" that I figured we just wouldn't see much of. If the "entire system" does deal with a year as 2 parts, then I guess this would work OK, at least for a while. LOL. I hope that "all" Y2K problems are as minor as these "display" problems. But, as "yes" just said, 19100-1999= ...

bbb,

I don't know who you've been listening to, but Y2K isn't about a computer CRASH, it's about DATA INTEGRITY. Yes, I'm verrrrry happy that we did make it thru the rollover with only minor problems. To be honest, I did expect more. But the fact is that we still have very little year 2000 data in the "world database," except for those few programs that do look-ahead processing. The fat lady is now on stage, and has just warmed up. She will begin to sing on Monday, when that 90% of computers that have been off for the weekend, are powered back on, and the data starts to flow. And she will be singing for a while, into month end, into quarter end.

Happy New Year everyone, and may this mess really turn out to be a bump-in-the-read. <:)=

-- Sysman (y2kboard@yahoo.com), January 03, 2000.


You are all missing the point.

'19100' is primarily a display problem, also known as cosmetic. On some systems, the internal date does not roll over - it goes from 099 to 100. The logic that deals with this date needs to take that into account. But if there are no calculations on the date, its just weird looking. If you try to calculate using that date, as the video rental store did, you will come up with people owing thousands of dollars in late penalties. If this had been the telephone company and not some dinky little retail store, the results could have been a lot more serious.

On many other systems, the date is stored in a two digit field. It actually rolls over - it goes from 99 to 00. The problem is when this field is used in calculations or as a key in a data base, you will have massively incorrect calculations. You may in some cases have the computer crash, but that is not the most likely result.

-- kermit (colourmegreen@hotmail.com), January 03, 2000.


19100 may indeed translate to "does not crash" in certain applications.

But it does *not* equate to "runs OK".

Ask yourself what would be the ultimate benefit of having a slow leak instead of a blowout, if -- instead of having your car stop immediately, it continued on, gradually losing traction, until you reached a curve in the road, and ended up flying over a cliff.

Sometimes it's *better* for a program to crash on the spot than to keep running with gradual corruption growing like a cancer.

And just so there's no ambiguity, I define "sometimes" as "almost always" in that scenario.

Any programmer can tell you that it's trivially easy to avoid paying for nearly *any* error on the spot. In VB, for instance, you can put an "On Error Resume Next" clause at the start of every procedure. Your program will likely *never* crash.

Eventually, however, it will produce nothing but garbage, and *may* in fact end up crashing the entire *computer*. But, "little" errors will be passed over without *any* notification to the user.

So, if you find any great comfort in the "19100" thing -- if you think that because it *doesn't* cause an immediate crash, it's a *good* thing, I suggest you reconsider. A slow-acting poison can be deadlier than a fast-acting poison, because by the time you realize something's wrong, it's too late to do anything about it.

-- Ron Schwarz (rs@clubvb.com.delete.this), January 03, 2000.


Though seen primarily as a display problem.  The real problem occurs 
when this date is stored in a data field:

1. If field is character(4): "1910" 2. If field is numeric(4): **** (overflow) 3. If field is date: Many possibilities all bad



-- Slobby Don (slobbydon@hotmail.com), January 03, 2000.


I've chosen to pay my bills this week by dating my checks with the year 19100.

I report back when they have cleared.

-- plonk! (realaddress@hotmail.com), January 03, 2000.


Moderation questions? read the FAQ