Y2K affected lots and lots of Cobol code and similar, archaic languages that use actual text to represent dates.

Unix, Linux, FreeBSD, etc all have an epoch, too. The world ends on January 19th, 2038, at 3:14:07, when 2^31 - 1 seconds have elapsed since 1/1/1970.

AOL has been bit by this already - some of their programs use a billion seconds as infinity and in the spring of 2006 the end of the world got closer than a billion seconds which broke some things.

If I recall, they had tons of 'old' computers that were made from the late 70's to late 90's that were NOT upgraded and allowed to pass through y2k naturally.

No, that is simply not true. I worked at NASA, as a CSC contractor, during the years running up to Y2K. We upgraded every computer on our site and made them Y2K compatable. A similar effort was made in all government sites as well as all banking and financial institutions.

There were no very old computers in use during those years. Those old mainframes were obsolete and cost more electricity to operate for a couple of months than a new computer cost. Plus they were much slower and had only a tiny fraction of the storage space. Remember computer technology, in speed and storage space, in those days was doubling about every 18 months. And the price of these new computers was tiny compared to the millions those old giant dinosaurs cost. There were simply no old computers in use in those days because of that very reason.

Any computer that still used two digit year codes, and there were a few of them, had serious problems. But the vast majority of them, at least 99%, had been upgraded to use four digit year codes.

Ron Patterson

Well, there were two approaches to Y2K:

1. Well financed enterprises and those having applicable regulation tested and fixed all software in advance. In the late 1990's I worked at FPL in Miami (a nuclear utility) where the expenses exceeded 50 million $US

2. The rest of the world simply let systems fail and fixed them afterwards, as is commonly done with software that runs annually such as year-end bookkeeping programs. Its far cheaper to fix it afterwards if you don't mind the consequences too much.

I hope that our Y2K experience does not harm us when trying to prepare for the downside of Peak Oil.

What a ringing endorsement! By a credible source!

People,People,,,it was not the computer handling the year funtion as so much as it was all the massive archived data that had 2 digit dates....no company that I know of went back and changed all those records to 4 digits EXCEPT the Social Security Administration....

What they did was put 'sliding window ' code in the applications , such as those written in CICS,IMS and so forth.

The computers ran the Operating Systems(and needed a tad of patching like when the app asks for the timer/date function), and the applications needed a huge amount of patching.

What I did was run the TOD(time of day) clock forward to past the 1999 date into 2000 and then the input folks tested it with test cases..and plenty of them fell right on the floor.

But of course most just used the old date by appending 19 to the front...so therefore 'windowing'.

And the reason for sliding the window is each year to move that window forward...

If you access a record and it has 02 in the date..then is it going to be consider 2002 or 1902? Simple example but many many more abound.

Take tape expiration dates..written in the 'scrtch' tape header as a two digit field...presto then on 2000 all tapes are likely expired...another example.

And so it was a hell of a bloodbath but of course out of view of Joe Sixpack so he just assumed 'Nahhhh all bulshit'
but the dummy never seen the programmers and testers behind the scenes..

Yes Cobol and Fortran code but also BAL and many many apps written in all kinds of languages, Clipper,DB2 and on and on and on...but mostly big mainframe application that very large businesses used...the server farms were just getting started you see.

So all the old date fields are still 2 digit..the code doesn't 'abend' but may put out erroneous dates..and that is strickly up to the data ops people and the maintenance programmers to ensure the 'sliding window ' code updates keep being used appropiately.

I had an acct that died on the rollover..it employed about 150 workers and they were without jobs..the mgmt didn't follow IBMs advice to update the mircocode in the minicomputer they used for accounting.

I ended up with it in my basement and later threw it in the dumpster.

I worked two years in contract consulting on mainframes testing and preparation. Everybody who had any sense in data operations and data centers were scared shitless.

Did I make a lot of money? Not that much..$37/hour and $8/hour perdiem...and I worked many 60/70 hour weeks..then later they wanted me to extend my contract and I told them $45 /hr..they bitched but that was really chicken feed...Today IBM IGS contractors can pull down $200 / hr..of course they don't get all of that.

So the problem of 2 digit date fields still exists but has had a bandage applied...I think in areas of stock keeping and many older records the problems still occur with getting the date wrong..but

Someone up line said all the old mainframes were gone then.

That is absolutely untrue. A vivid example was air traffic control systems and the FFA...they were still using IBM mainframes with thermocouple modules and still be cooled by water chillers. I know for many retired guys were called in to fix them since all the new folks hired didn't know shit about them.

airdale-check my bio if you wish

PS. All this time and still many get it wrong!!!
Don't believe me? Google this : y2k window sliding code