Y2K Testing

The Year 2000 Problem was by far the biggest computer bug ever highlighted. It was noted as effecting everything which had a computer device. The stories before the tick toc of midnight on 31st December 1999 were that computerised equipment was going to fail and the list of failures to expect, ranged from your home video recorder freezing, speed cameras used by the police force, bank doors with auto locking throwing them selves open, burgular alarm systems going off all over the country, air planes falling out of the sky, nuclear power plants exploding and nuclear weapons firing at will.

Luckily we made it to January 1st 2000 and the silent anticipation within those first few seconds was eerie to say the least. everyone threw their hands in the air and they said “what was all the fuss about”. All of us in the testing industry breathed a temporary sign of relief after we had resolved any of the small issues which were picked up by the disaster procedures in place.

The Y2K threat was very real, the force identifying and resolving the problem was the biggest the planet had/will ever see. Nearly every program I tested during the 18 months working on this problem failed in one way or another. Y2K highlighted how under valued testing had been up until that point.

Below are the standards and a description of the problem.

Y2K test procedures and standards.

The purpose of this document is to set the standards and outline routines which will be used for testing hardware products for Y2K compliance.

The Y2K supplier program team will in principal adhere to the BSI definition as outlined in their document: DISC PD2000-1 A Definition of Year 2000 Conformity Requirements.

The Definition

The BSI document addresses four areas of the Y2K bug:

Rule 1. No value for current date will cause any interruption in operation.

Rule 2. Date-based functionality must behave consistently for dates prior to, during and after year 2000.

Rule 3. In all interfaces and data storage, the century in any date must be specified either explicitly or by unambiguous algorithms or inferencing rules.

Rule 4. Year 2000 must be recognised as a leap year.

(For the full BSI document, see appendix A)

Additions to Definition

The BSI statement of definitions takes care of most circumstances. The exception being infinity dates.

Some code has 9/9/99 or 9/10/99 as an date for expiration of data which needs to be available for a long time, or as an end of field entry. Either function may cause problems rolling over onto that particular date.

This is a function, which largely affects products such as databases and accounts packages, but may possibly have some effect on operating systems.

In order for a product to be certified compliant, it must satisfy the four rules of the BSI definition, as well as the addition.


The Y2K problem in detail

The Millennium bug refers to the way in which computers store and process date information. Twenty years ago when computer memory cost several thousand times what it cost today, some bright spark thought that representing dates with only a two figure year would save substantial amounts of money. This was correct for that particular epoch. The problem is that this style of programming was carried over into the nineteen nineties, where memory has become cheap.


The Y2K Problem and PC Hardware

Each computer has a hardware clock (real time clock) and a virtual software clock (system clock). The real time clock (RTC), is hardware based and usually integrated onto the motherboard whereas the system clock is a BIOS function which is responsible for interpreting the data received from the RTC.

The function of the RTC is to increment the system time 18.2 times a second. This function is not aware of centuries, and only tracks years as double figures. It is up to the system clock to interpret the date received and infer which century is intended.

The system clock relays its interpretation of the RTC time to the operating system, which uses this data for time stamping files, processes and various other functions.

In operation, the RTC is only active when the computer is turned off, and during the bootstrap sequence. Once the BIOS has been loaded and the system clock has been set from the RTC, the two clocks run separately of each other. This means that it is possible for the RTC and the system clock  to go out of sync, or one clock to be set to different time to the other by an application or operating system. In practice this is not a problem.

Problems of Interpretation

With most computers, the RTC only supports a two digit year field, with no century data. The BIOS is responsible for century interpretation, and usually employs an inference rule. This means that date information smaller than 80 is interpreted as 20xx, and dates above 80 is interpreted as 19xx. The dates, which interpret the year, may change, but if the BIOS interprets at least two decades in advance, this should not be a problem. The Windows range of operating systems, does not register dates earlier than 1980.

The Y2K Problem and PC Software/Operating Systems

Most operating systems are affected by the Y2K bug to some degree. Recent operating systems, with their multitude of peripheral applications, drivers and interfaces, may present problem on several levels. An example of this is Windows NT4, where the runtime engine is unaffected by dates, but the user manager does not recognise the Y2K as a leap year.


Software Tests

There are number of software packages which can be use to verify the compliance status of a product. These software packages typically test a number of features of the operating BIOS, hardware and operating system. Typically, features tested are the BIOS interpretation of the year digits, plus several rollover test, which may require rebooting the machine several times.

Operating systems may be tested for the rollover behaviour, as well as their interpretation of system dates with BIOS’s with two and four digit date fields.

In addition to the test above, data files (e.g. spreadsheets, databases) may also be tested for compliance. This is to ensure that data files from legacy applications  store dates in a compliant format, and will not malfunction if an application attempts to read them.

Software test are executed on the computer, and check a number of parameters including how the RTC and system clock handle date formats, they may also check how the operating system handles rollover dates, and whether 2000 is a leap year or not.

Although the testing procedure can be automated, this will not allow for the rollover test to be performed with the machine turned of, one of the most common Y2K errors. When this occurs, the system clock usually resets itself to 1980.

Remedial Actions

Y2K BIOS Fixes

Most PC’s which have a Pentium processor or later, have a user upgradeable BIOS and as such can be upgraded by running an application which installs an updated BIOS. However, not all Pentium computers have BIOS’s available, which are millennium compliant.

There are three options for machines with which the BIOS can not be updated to a compliant version. These are explained below.

Y2K Hardware Fixes

These are usually the add-on cards, which fit into one of the ISA slots on the motherboard of the computer. Theses devices replace the firmware of the machine in which they are installed, so that the standard bootstrap is by-passed, with the PC booting from the add-on card instead.

Y2K Software Fixes

The majority of companies marketing Y2K test software also have a operating system patch, which will ensure the machine rolls over to the relevant date. This patch may achieve this is several ways, checking what the date on the machine is, and prompting for correct date, or reinterpreting information supplied by system clock.

Utilities that patch errors introduced by the BIOS must be loaded every time the PC is turned on. Although this is a relatively simple, inexpensive solution it is also fallible. If an engineer or user changes settings in the configuration files, the machine may revert to noncompliant status.


Scope of Tests

The millennium bug affects a wide range of machines. Not just computers, but also network devices, communication protocols, Operating systems and peripheral devices.

Test Methodologies

Testing of BIOS’ should be performed in a non-live laboratory environment, in order to preserve data integrity.

The test strategy should encompass all the key test dates. Specifically, it is important to check rollover on the following dates:

A.     08.09.1999 to 09.09.1999

B.     09.09.1999 to 10.09.1999

C.     31.12.1999 to 01.01.2000

D.     28.02.2000 to 29.02.2000

E.      28.02.2001 to 29.02.2001

F.      28.02.2004 to 29.02.2004

G.     28.02.2002 to 01.03.2002

H.     Enter invalid date and check system behaviour


The specific dates above test all crucial dates which may affect hardware compliance.

A and B are the end of field dates. These are not usually a problem with BIOS’, but may still under certain circumstances cause a problem.

C is the millennium roll-over date and the test of primary concern.

D, E, and F test for leap year compliance.

G tests for correct date handling on non leap dates.

H is required to check for system behaviour if an incorrect date is entered/received.

In addition to rollover dates, the range of dates allowed should be tested for. i.e. earliest and oldest date, and the interpretation of short date formats, i.e. what does 00 represent. If the BIOS interprets noncompliant date formats using inference rules, what are these and will the machine function as expected until the year 2020.

All rollover tests must be performed so that the machine roll’s when booted with a compliant operating system, in BIOS mode, and with the machine turned off. Only if tests are performed in all these modes, can reliable results be obtained.

Test Procedure

Each test must be carried out by a competent engineer, following a detailed test script (sample test scripts are in appendix B). Expected results should be listed as well as actual results.

www.Surfersjunkyard.com contact me on admin@surfersjunkyard.com