The millennium bug may have survived being crushed under the foot of IT fixers.

My first inkling was in West London. Suburban wives and house husbands vying for parking spaces in a crowded street, and in the midst of this, two BBC researchers, a sound engineer, cameraman, my PR lady and me. My first TV story on Y2K, and it wasn't going well. When I first took the call from the BBC's Watchdog team, I was over the moon. By the time we actually started filming I should have been barking at it.

This was in early 1997, and the media had just woken up to the computer industry story of the decade, some would say of the century. The problem even then was that Y2K was not quite what they wanted. At least it didn't behave well in front of the cameras and TV companies (as I later learned) don't like that.

The researcher found a proud mum with a PC in her daughter's bedroom. We checked it – sure enough the hardware thought 1999 was followed by 1980, and most of the software programs had ‘issues'. Note that I was careful even then to talk of issues, rather than problems or failures. “Make it show us the problem then,” requested the researcher, rapidly followed by: “Is that it? Where is the smoke?”

She genuinely thought that the PC would start to smoke, and hence would be good TV. She stomped back to Broadcasting House muttering.

But what is was/will be the Y2K problem? Because it is not over yet.

Any computer system basically comprises five parts – the hardware, operating system, software, data, and the data sharing mechanism. And it's because of the tedious technological side that the media got the wrong end of the stick.

All PCs run a Basic Input/Output System (BIOS) program before any operating system or other programs are started. The BIOS is designed to initialise the PC so that it becomes aware of its hardware configuration, such as hard and floppy drives, video drivers and keyboard parameters. It also sets up the system date and time by reading values from the real time clock chip, which is battery-powered (rechargeable) to keep a constant time reference for the PC.

As with many year 2000 problems, it is very difficult to apportion blame or liability. Certainly, suppliers of affected software would be fairly justified in claiming that the year 2000 is not a problem with their programs as these systems work fine when fed with the correct date by the BIOS. And so starts the finger pointing.

In many cases, the BIOS manufacturer is not the same as the PC manufacturer, and mutual liability clauses between supplier and manufacturer serve to protect the entire supply chain to the user. This leaves the end user in a vulnerable position, and one from which it is difficult to escape without hardware replacement. Most pre-Pentium PC hardware platforms don't change smoothly from 31 December 1999 to 1 January 2000. Many of the Pentium machines I have checked also have problems, but at least some of these manufacturers created their own fixes.

This hardware-level problem is probably the simplest in the whole Y2K arena to check and fix, but many end users will have compromised their PC's warranty by using unauthorised fixes. If you are faced with a Y2K claim, it might be a good idea to check this first.

Soft and squidgy
If the PC BIOS were the maximum extent of year 2000 problems with PCs, life would have been simple. But the real problems are far better hidden.

Many programs and some of the common operating systems had issues and concerns in dealing with dates approaching the end of the century. And some of these continue even today. One of the simplest fixes in one of the Microsoft products fixed 1901 as 2001, but then progressed from 2001 to 1902. Whether anyone will admit or discuss problems arising from this is unsure, but don't hold your breath.

In the case of operating system problems, these are mostly related to referred issues from the BIOS. However, there are a few well-recorded and acknowledged problems with files, documents, etc, created in the year 2000, where the file create date may be 1/1/!* or similar invalid characters. These files may then cause referred issues with other programs which attempt to validate the date stamps on files, with the likely result that such files will be rejected or cause the program to crash. I have created examples of this under laboratory conditions, and have seen this problem cause the PC to freeze and require a reboot with a consequential loss of data.

In October last year, a story came to light that hundreds of thousands of UK pensioners had received miscalculated amounts of money. This was exactly the sort of result which a Y2K software problem could have caused. The interesting point with this example was that by October 2000, talking about Y2K was about as hip as reminding your teenage daughter that you used to wear flares. No one mentioned it. It was dismissed as a ‘date-related computer problem'. If I remember rightly, that was the very definition I gave for Y2K originally in a document which was copied over 12 million times and handed out by seven national governments.

And then there was data
In the beginning, there were no computers. And Man thought something was missing. Even the digital watches ultimately failed to satisfy, and the computer was born. But what was the reason? Was it to complicate simple tasks? Make spotty teenagers rich? Infuriate parents? No, computers were invented to process data quicker than humans can. That was it. Many would argue it's been downhill ever since.

The tricky thing with data is that for most of the time we ignore it, lose it and hide it like nuts in the autumn. Finding it, testing it and having the nerve to throw away the useless stuff is hard. Even worse, user data may often seem to be correct when it is displayed on the screen but, when you dig into the actual stored information, it is found to be corrupt or flawed. For instance, when date sensitive programs are run before the date is reset, the resulting false date may propagate and cause some programs to perform wrong date-specific operations, such as deleting data relating to dates which are incorrectly assumed to be in the past.

For example, one of the UK logistics companies ran a DOS-based billing system which created invoices. The date of the invoice was read from the operating system and on a couple of PCs the BIOS rolled over to 1980. Invoices created in 2000 were dated in 1980. In fact, while the user continued to print these invoices and even managed to collect payment, the internal operation of this billing package correctly assigned this invoice to the year 1980 so these invoices did not show up in the accounts for the year 2000. In such a case, who is responsible? Who should have fixed it and who should pay for the fix?

Widely explained in the press, the year 2000 was a leap year, although I did notice a lot of presenters talking about 365 days in 2000 last December. And it was also widely reported in March that the leap year variant of Y2K did not appear. Except that it did.

On 1 March, the US President's Council head, John Koskinen, reported 29 February problems in the Department of Housing, Forest Service, National Oceanic and Aeronautics Administration, FCC, Coast Guard, Correctional Pharmacy System, and the Immigration Service. 1

And in my opinion, those were just the icing on the cake.

Dirty data
Part of the attraction of the PC culture is the ability of PC programs to exchange data. This gives rise to yet another layer of the problem: one program can pass corrupt information to many others with unpredictable results. Date errors may crash the program, change data or even cause data to be deleted as erroneous entries.

During the first few months of 2000, 19 of the world's 434 nuclear power stations experienced unforseen Y2K problems. The stories made minor news, but surprisingly there were no screaming headlines nor politicians making waves.

Five of the American faults were reported to the US Nuclear Regulatory Commission as “problems which occurred with physical plant access control, monitoring operating data, and calculations in meteorological data”2. The two Spanish nuclear problems were reported by CNN as “hiccups”. In Japan, Shiga and Onagawa stations reported “problems displaying data on radiation emitted to the environment” and Fukushima experienced a failure with “the system that shows the position of the control rods in the reactor core”3. In this last example it turned out to be a hardware clock which fed data to the control computer. For some unknown reason this clock rolled from 1999 to 6 Feb 2036.

But we survived. As we predicted. Forgive my smugness, but thankfully the hard work has paid off – so far.

And now?
In September 2000, there were 32 ‘sue and labor' cases in the US totalling $10bn in claims and a few rumblings in the rest of the world. Nevertheless, there does not seem to be the mass of litigation the media warned us about. One of the enthusiastic lawyers, filing a $183m claim for Xerox, said, “There are going to be billions and billions of dollars of claims.”

The question in the legal minds seems to be, “Who will pick up the tab for all the precautionary work done in preventing the problem?” And with a twist worthy of Machiavelli himself, a 17th century maritime clause has been dusted off and used in a dozen lawsuits against insurers.

Originally, the sue and labor clause was applied to compensate shippers for the cost of preventing unforeseen catastrophes. The captain of a ship caught in a storm, for example, may throw cargo overboard to keep the vessel afloat. The clause provides that the insurer would reimburse him for the cost of the lost cargo.

The key defences in these cases are that Y2K was not an impending disaster, is not a natural phenomenon, was predictable and not unforeseen, and that upgrading and fixing computers is a commonplace business activity. Bob Hartwig, chief economist for the US Insurance Information Institute, summed it up nicely: “It should strike everyone as strange that people are suing to recover losses when there haven't been any”.4

As ever, until we have some case law it will remain unclear but there is obviously a small risk that such claims may be successful.

Today, the watchword is caution. Y2K has always been about risk assessment, and there is still risk. The chances of major claims may seem increasingly slim, and the media may have lost interest, but Y2K risk is, was, and always will be real. Even if smoke never did come out of the back of the PC when the BBC wanted it.

1 CNN, 3 January 2000

2 CNN Techweb, 10 January 2000

3 President's Council on Year 2000 Conversion Report, 1 March 2000

4 “Y2K Iceberg ahead”, 14 September 2000