What is the Year 2000 Problem?

This is a brief summary. For more information, consult any of the repositories indexed under External reference information.

Warning.  Before doing any testing, make sure that disk files from your system are fully backed up, and that you have a system startup disk which will start your computer in an emergency.
 

The providers of these pages cannot accept any responsibility for any loss or damage to your system or data.
If in doubt, consult a qualified professional


NOTE: The four volumes Year 2000 - A Practical Guide for Professionals and Business Managers,  published by the British Computer Society, are now available free online in PDF format. The working party including Royal & Sun Alliance Insurance, Bradford & Bingley Building Society and Shell International Ltd.

Outline of the problem

Many present-day computer systems and programs are unable to handle dates past the turn of the century. This is often called the Millennium Bomb.

The Pocket Website prefers to talk of the Century Challenge because the same issue is faced whenever the century is needed to distinguish between years. Nineteenth century (or earlier) dates cause the same problem - for example, in


Why did it happen?

Early computers were very limited in capacity. Memory for processing calculations was very expensive. Magnetic tapes and magnetic disks were available for off-line storage, but were also limited in capacity and were costly. To do useful work with dates, the century was omitted to save space, time and money.

It's a human problem too

We miss off the century for convenience even in everyday speech. We talk about "the sixties" (the era of the Beatles), or "the nineties". Of course, "the nineties" would have meant something very different to our grandparents or great-grandparents, and that is the root of the problem.

Human beings don't need to be taught how to make assumptions from the context about the missing century. Computers are not intelligent like that!

Leaving off the century gives what is commonly called a six digit date. It may occur in various formats such as 12-Jun-95, 12/06/95 or 95/06/12. Symbolically we can represent these century-challenged formats as dd-mon-yy, dd/mm/yy or yy/mm/dd.

Other formats are also possible. In the USA, mm/dd/yy is common and 12/06/95 means 6th December 1995, not 12th June. This just makes things more confusing.

Give me a simple fix! (sorry, no)

To fix this problem, you either have to give the program some means to make an assumption about the missing century; or you have to modify programs and data to make the century explicit. Including the century means you move to an eight digit date such as 12/06/1995 (dd/mm/ccyy) or 2002/06/12 (ccyy/mm/dd).

One good reason for changing is that, after the century change, six digit dates such as 04/02/01 are highly ambiguous.

A common misconception is that systems will only fail after the clock rolls over to 1 Jan 2000. This is not true! Systems may fail when they first have to handle a date after 1 Jan 2000 ... for a program which plans forward more than three years, this threshold has already been crossed, in 1997. There is now only one complete tax year before the rollover: April 1998 to March 1999 in the US and the UK.

Can't I just sue somebody? (sorry, no again)

Of course, if you can prove your supplier was at fault then you might be able to recover damages. Expect some major lawsuits, especially "class actions" in the United States.

But even if you win, you'll still be left with the problem. Especially if your supplier goes out of business as a result. And in any case the legal definition of compliance is far from straightforward.

It seems far more useful to work positively with your suppliers if they are cooperative. Most are. Keep legal action a long way in reserve; it's a last resort!

... OK, so how much will it cost?

Well, as you'd expect, it depends! But the figures can be enormous and are growing all the time. Worldwide, estimates range from 50 to 300 billion (yes, billion) US dollars. Basically that's because a lot of the work is labour intensive. Read on - it's not just about finding and fixing code; there can be substantial testing and data conversion included too. Now, in mid 1998, a lot of companies are waking up to find all the best people and solutions providers have already been hired; they're having to make do with less expert people, at higher cost. And those that already have people are having to pay more to keep them. The early estimates of around US$1.20 per line of Cobol code, or its equivalent, have probably at least doubled.

Another way to look at it is that many enterprises are spending a third or more of one year's IT budget to deal with the problem. That may be a better guide as to whether your own estimates are reasonable.

Back to Index

Where must we look

There are three main areas to look out for: hardware, software and data. Hardware problems include those which are specific to embedded systems.

In addition, when you have fixed it, you have to make sure that you don't reintroduce the problem. This is a particularly easy trap to fall into if you exchange data with colleagues, customers or others; their systems may not be compliant! You need to plan your conversion in consultation with anyone you work with.

Consult your supplier and ask them for a statement about Year 2000 compliance of your equipment and software. The British Standards Institution provides A Definition of Year 2000 Conformity Requirements.

For more information on conformance standards, see our Standards page.

Many vendors now provide information on their Web sites, and we provide an index to some of this vendor information.

Back to Index

Desktop, server and mainframe hardware

For PC users, the commonest failing of the PC itself is that, after 31 December 1999, it becomes unable to remember the date when it is switched off. Most failing PCs seem to reset to 4 January 1980. This is quite easy to test, and can be rectified through the DOS command DATE or through the Windows system settings.

This makes it sound simpler than it is, however. On PCs you have to take account of

Remember that many PCs, especially cheaper ones, use chips from sources other than Intel (they are not necessarily better or worse, just different). Also, some fixes work by providing a resident program which, in some circumstances, may not actually kick in. You can still get incorrect dates back.

For more detailed information on the underlying problems, look in our repository index.

Apple Macintosh and the many Unix systems don't have this problem, though Unix and older Macs will run out of dates later in the 21st century. Windows NT is claimed to be compliant but must be run on compliant hardware. For proprietary mainframe and server systems, consult the vendor.

Back to Index

Embedded systems

Embedded systems have microprocessors integrated into their control or management systems. Sometimes these are general purpose processors similar to those use in desktop computers; but they may be highly specialised devices.

Embedded systems can experience the date challenge in highly specific ways. For example, failure of the system clock may cause the processor to shut down even if the function which it is controlling doesn't appear to be date dependent. Since equipment vendors often purchase chips from several sources, machines which are apparently identical may have different date challenge characteristics.

The Pocket Website has a page of information about embedded systems.

Back to Index

Software

All your software needs checking.

Many software vendors will supply versions in due course which will be capable of handling 21st-century dates. Most apply a technique called windowing to let the software make an intelligent guess if the century is omitted.

The problem with windowing is that different vendors make different assumptions. In any case, the vendor's assumption may not suit your data. It's your responsibility to match your needs to your software's abilities.

Expanding dates to 8 digits is safer if you can do it in time and get it right! There are exceptions however, especially if:

If you have written your own software - and this includes desktop applications like spreadsheets, if they store or manipulate dates - then you will need to check it carefully. Business planning or forecasting systems may be your highest risk - give them priority!

Back to Index

Data

Even if your computer hardware, its operating system and all your software are fully Year 2000 compliant, you still need to manage the correctness of your data. One of the oldest and still most valid principles of information management is GIGO. Garbage In: Garbage Out.

When you have modified your software to handle year-2000 compliant dates, it is more than likely you may need to convert existing century-challenged data. Software conversion will not magically change data you've already got from six digit dates to eight digit dates!

If software previously expected a six digit date (yymmdd ) but now expects an eight digit date (ccyymmdd) you will need to modify existing data accordingly. It's impossible to give general guidance, because everybody's requirements will be different!

Back to Index

Keeping watch

Even when you have converted all your systems and data to the new standard, the process is not complete.

You have to be on your guard if you receive data or programs from other people or other organisations. If they have not converted, your friend's spreadsheet may reintroduce the problem.

This is why some people call the Century Challenge a virus: it's not malicious, but careless data exchange can "reinfect" your system.

Back to Index

Planning

The key to success is planning. Work out exactly what you have to do, and when you can do it. And good luck!

Back to Index

Some key dates

Here are a few key dates to watch out for. Based on information provided by Year 2000 discussion group contributors, John Ivinson (BCS Computer Bulletin, October 1997) and others.

Back to Index

TopReturn to Pocket 2000 Home Page

Original material Copyright © Tony Law/Parkside Information Management 1997, 1998