A few months ago, I was at a cocktail party, and I met a retired programmer who used to work on the billing system at the local university medical center/teaching hospital. He retired shortly after the hospital's Y2K team was disbanded. He said that they had worked on the problem for over a year, and that the calender rolled-over without any major hitches.

I asked him why there weren't any major hitches, either, in ex-Soviet-block countries or third-world countries, where nobody even *tried* to fix the Y2K bug. He seemed slightly offended at the question and didn't even try to answer it.

So... what's the scoop? Was the Y2K bug the sasquatch of the tech world -- a glorified urban legend?

J. D. Trollinger
Wednesday, August 21, 2002

At the company I was working at in 1999, they had a computer system that was going to be replaced well before 01/01/00, but
things kept being delayed and it wasn't until the end of 2000 that was finally deployed.

To give you an example, a few months before 2000, invoices were suddenly being printed with a 1968 date, (don't know why, my job was elsewhere)

But by 01/01/00, all the problems had already been patched.

Andres
Wednesday, August 21, 2002

Any decent programmer who is looking to save a few bytes when storing a date field, would definitely NOT store it as a separate day (1 byte), month (1 byte) and 2-digit year (2 bytes), but as the number of days since 1900, for example, so you can fit nearly two centuries in a 2-byte integer.

The media always assumed that you store dates as ASCII values while that is about the worst choice that you can make. I guess this explains why there weren't such major problems after all.

Frederik Slijkerman
Wednesday, August 21, 2002

The urban legend I heard was that the US government once mandated 2-digit dates in one of its specs, which helps to explain the prevalence of 2-digit dates in the West compared with in ex-Soviet-block countries.

Christopher Wells
Wednesday, August 21, 2002

Like many things, the Y2K bug was blown out of proportion, but it was a serious problem. Many of the problems were cosmetic. For example, I had a script on my website which went from displaying "1999" to "19100".

Many applications simply store and display the last two digits of a date. For the most part these didn't need a lot of changes, but anywhere that compares dates was likely to cause problems. For example, an order with an invoice date in 99 and a delivery date in 00 might tell you that the delivery date cannot be before the invoice date.

Now you could write code to fix this, or you could say "it's only going to be a problem for a couple of weeks. We'll cheat and put in a fake date for those couple of weeks."

Many older video recorders consider dates after 1999 invalid, but they can be coaxed back to life by setting their clock back to 1972, which has the same days of the week as 2000.

You can take three approaches to the problem. You can do detailed analysis, fixing and testing to make sure you won't have any problems, or you can sort out problems as they occour, or you can just live with the problems.

While we in the west tended to take the former approach, poorer countries tended to rely on the latter two. However as they tend to be less reliant on technology their systems tend to be far less automated, and are likely to contain far fewer date-critical components, and to a certain extent they just lived with any problems which did occour.

I think the media can be blamed for hysterical reporting. However the technology people share a lot of the blame for failing to provide factual information (largely because they didn't really know).

Back in 1999 I was at a panel at a SciFi convention about Y2K, claiming not much would happen. Sitting next to me was a so-called expert who'd moved to the West of Ireland to escape the worst effects, who was claiming that civilisation would grind to a halt as a result. Who do you think the media listen to?

However, even I was surprised how few problems occoured.

James Shields
Wednesday, August 21, 2002

> However the technology people share a lot of the blame
> for failing to provide factual information (largely because
> they didn't really know).

I wonder just how much of this failure to provide factual info was caused by potential gains rather than ignorance.

Well, we all got families to look after, right? And large houses with pools and tennis courts to maintain... don't we? ;)

Paulo Caetano
Wednesday, August 21, 2002

And Yourdon has got books and conferences to sell - with lots of willing victims lapping his BS up.

Nat Ersoz
Wednesday, August 21, 2002

"Any decent programmer who is looking to save a few bytes when storing a date field, would definitely NOT store it as a separate day (1 byte), month (1 byte) and 2-digit year (2 bytes), but as the number of days since 1900, for example, so you can fit nearly two centuries in a 2-byte integer."

Works fine in C, doesn't work so hot in COBOL. Where do you think most of the Y2K problems were?

jeff
Wednesday, August 21, 2002

I think that the media hype and fear of law suits caused many companies to spend way too much on the Y2k "problem". I spent time on the Y2K team of a major regional bank and between 5 coders, 5 "managers", a couple of disaster planners and 15 QA people, we found a handful of bugs, most of which could not be considered critical.

When I asked the project manager about all the wasted money, I was told that spending the money, by itself, helped insulate the bank from law suits if a problem occured.

Bored Coder
Wednesday, August 21, 2002

I have a friend who works for Citicorp. He says that shortly after New Year's day, 2000, the company received an angry fax from a customer who included a copy of his latest Citibank statement.

The statement was all messed-up, with nonsense dates like 19100, etc.

The fax threw the IT department into a panic. Eventually, though, they realized that it was a hoax. The prankster did a nice job on conterfeiting the document, though.

J. D. Trollinger
Wednesday, August 21, 2002

Did any of you actually work on Y2K fixes? The reason nothing huge happened is because WE FIXED THE PROBLEM ON TIME. It pisses me off every time someone says it was a hoax. This is one of the few cases I know where a group succeeded at its goal to prevent problems, and afterward everyone else said there never were any problems. That's like thinking the floor never gets dirty because you come in 1/2 hour after the janitor left -- it was plenty dirty before you saw it, and someone busted his butt to clean it.

I worked with a team that patched multiple apps that most definitely would have errored on 1/1/2000. About 3/4 of these apps were for the FAA, and they crossed many programming languages, platforms, and systems. All you that are saying what should have or shouldn't have been done need to realize that the nice little datetime datatypes haven't always been available, and some of these apps were written 20 or more years ago, so who knows what the hell the original programmers were thinking.

I guarantee you the problem was real, and many hard-working programmers put in lots of time to find and fix these problems. The vast majority weren't serious, but there were enough that were serious and could have caused major inconveniences and outages.

Troy King
Wednesday, August 21, 2002

"I guarantee you the problem was real"

Maybe, but this still doesn't answer the question of why nothing bad happened in countries where nobody tried to fix the problem.

.
Wednesday, August 21, 2002

"Works fine in C, doesn't work so hot in COBOL. Where do you think most of the Y2K problems were?"

Most of the expected results from the problem were "hype". As valid as the great productivity that will result from the next silver bullet soon to hit the marketing department of your favorite software vendor...

While I didn't care to get involved in the great rush to fix Y2K problems, I did spend a fair amount of time fixing problems caused by the Y2K fixes.

Joe AA
Wednesday, August 21, 2002

Cobol supports typed data, not necessarily the same was as in "C"...

A "PIC S9(04) COMP" (or COMP-4) would be a two byte signed integer... called "binary" by most cobol people, and a half-word by most mainframe assembler types.

"PIC S9(09) COMP" would be a fullword... binary... 32 bit integer.

Joe AA
Wednesday, August 21, 2002

The reason that you did not hear of any Y2K problems in the rest of the world, is that America, especially the media, does not pay any attention to the rest of the world.

Another reason is that computers are not that well used in the 3rd world. Yes, there are computers there, but for serious automation, the systems would have been sourced from the 1st world, and the vendors would have fixed them.

And have you also considered the possibility that the 3rd world ran their own Y2K projects? And since most of the 3rd world code was newer, it may have had a lot less problems.

Evan
Wednesday, August 21, 2002

The problem was real and many programs did fail because of Y2K. One of the myths was that everything was going to fail on Jan 1 2000. Programs started failing years before 2000 and were fixed as they failed. Master Card and Visa sent out cards 2-3 years before Y2k with a 00 expiration date and may of the reader systems failed to process the cards. It was a Y2K bug but it hit early. There were stories of inventory systems trying to throw away stock because it expired, again years before Y2k.

Another factor is that many computer systems fail regularly, the Y2k failures were handled in the normal maintenance cycle.

John McQuilling
Thursday, August 22, 2002

Let's also not forget that one of the biggest concerns was the financial sector. But when you think about it, banks had to deal with the problem back in 1970.

There are an awful lot of 30 year mortgages out there.

Chris Tavares
Thursday, August 22, 2002

I had a couple of Y2K projects, I had one client whose hire car software over fixed the problem and we ended up with dates starting in 3800.

It didn't exactly take a lot for their vendor to fix that.

Other than that I wrote a Time and Attendance Application to replace a client's existing Xenix software.

Simon Lucy
Thursday, August 22, 2002

Yep, fixed a couple of Y2K bugs at the current employer. Their previous solution was to hire a consultant to write new software with much diminished funtionality to replace the inoperable. Seems the original programmers played fast and loose with VB's weak datatyping. <sigh>

Greg Kellerman
Thursday, August 22, 2002

Y2K isn't real.

Y2K is integer.

Bill Godfrey
Friday, August 23, 2002

Ask Andersens, PWC, Deloittes, etc etc all the major accounting companies milked Y2k for all it was worth, I'd say they poured most fuel on the hype as well.

The real problem was surely the amount of *rse covering that wasted millions of hours of effort as every product was expected to certify that Y2K would not be a problem.

My house survey contains a disclaimer to the effect that there is no guarantee that it will not be affected by Y2K problems! Apart from a central heating timer it has no electronics. And the survey would have been better employed pointing out that the timer in question is taught as an example of a bad user interface - something that riles me several times a year, not once a millennium.

"The customer wants a guarantee that the system will work perfectly on 1 January 2000."

Fine. Just so they don't want one for every other day of the year. Why would they need a support contract then?

There was sensible software maintenance activity, over years, as others have mentioned. The rest of it was a huge exercise in pretending that risk can be eliminated, or offloaded onto others.

"Have you woken up to find that your 1999 calendar has all the wrong dates on it for 2000? You may have a claim!"

I read recently that there are now 1,000,000 plus lawyers in the US alone. It may not be Y2K, but that is a real problem.