Y2K was a bust because computer chips do not measure dates. They measure the difference in time, usually since a certain date. So turning over a given mark in time means nothing to the chip. That's why nothing happened on Y2K. Y2K was simply another tick in time for the chips.
Software issues with Y2K could be duplicated in a lab setting so they weren't a problem.
Theoretically, the Y2K phenomena will occur when the time difference exceeds the size of the variable holding the data. But that will be on a machine by machine basis since they were all made at different times.
Um, LOL!
Thanks for explaining things to me... but the thing is, you're wrong.
In an earlier "life" (burnout sux), I was a programmer -- and a writer, who wrote (books, magazine articles) about programming.
Your explanation is just so far off the mark that I don't know where to begin, other than to say that there are SO many potential "gotchas" when dealing with "date math" (and even NON-"math" date functions, such as buffer-overflow considerations, rollover/window framing, and so forth), that NO simplistic "one-size fits all" explanation is useful.
Trust me on this -- unremediated "rollover-unaware" software was fully capable of bringing this nation to its knees. The fact that it didn't (and please understand that there were plenty of nightmares that did happen, but were kept out of the news) is evidence that enough remediation was successfully completed to staunch the immediate effects of the problems (plural).
(BTW, you did notice that the stock market went south right after rollover, didn't you? There were a lot of accounting nightmares that took their toll -- silently, as far as the Happy Trusting Public was concerned).
There are STILL "Y2K bugs" cropping up -- and they'll continue to crop up, with no warning. Far too much code was "remediated" by use of "windowing" techniques. And those "windows" are closing, one by one, as time goes on.
A lot of "fixed" code wasn't really fixed. It was just shoved to the back burner -- on a stove that tilts to the front.
And I don't even want to think about how many "remediators", having slapdashed in some "windowing" fixes, collected their fee, and got outta Dodge as quickly as they could, leaving no forwarding address :) and NO documentation on their "fixes". (When working under the gun, the first thing to be tossed overboard is documentaion OF the work. So, the "window" elapses, and *boom*, right back where we started (with whatever code is in question), only this time, it takes us by surprise.)
The ONLY "simple" explanation for "the problem", is that it was a conceptual bug. People "thought wrong", based on what seemed right to them -- without actually analyzing the situation.
Gee, sort of like how the Warrenites get deceived, come to think of it!
So, what WAS the conceptual error? It was bad common sense.
"Everyone knows" that seconds roll over, and minutes roll over, and hours roll over, and days roll over, and weeks roll over, and months roll over, so of course YEARS roll over too!
Great logic -- except for one thing. Years DON'T roll over!
Years are linear, not cyclical.
Because the calendar LOOKS "cyclical" to humans -- and because they are predisposed to think in those terms, since every other unit of time measurement below "the year" does roll over, well... it was an easy mistake to make. Real easy.
But hard to fix!
And, as I said, a lot didn't get fixed. We're going to be living with Y2K for a loooooong time, and there's no way of knowing when something really ugly is gonna pop up with zero warning.
Buffer size (or variable range issues -- not sure which you're talking about here) are NOT the whole story, not by far.
Theoretically, the Y2K phenomena will occur when the time difference exceeds the size of the variable holding the data. But that will be on a machine by machine basis since they were all made at different times.
The biggest problem is that people thought of years in terms of cyclical operations -- as if years "rolled over", when in reality, they don't.
But the biggest problem that was created as part of the "fix" -- which will contine to haunt us for years to come -- is the patch-job "remediation" in the form of "windowing" -- which maintains the false notion of years "rolling over", and only pushes the imaginary "rollover" a few years into the future.
And "the future" just keeps on happening!
Some code really WAS fixed. Years are no longer pretended to be cyclical. Intead, they are handled as linear, incrementing by one, once per year. No "rollover" involved at all. That code will be fairly stable. I say "fairly" because all code has bugs -- and they don't present themselves other than "by surprise", i.e., "in the field". (Otherwise, they'd have already been fixed!)