Y2000 Compliance Issues

WG2-0010
CSSA/PMI Y2000 SIG WG2
http://www.cinderella.co.za/yi001y20.htm
Last update 1998-06-20

Problem Statement

The incomplete storage of date data and resulting incorrect interpretation of that data will give rise to what is known as the Year 2000 Software Problem. This has occurred in a number of ways:

Date values are stored without explicit century digits.
Date values are stored as counters where the highest value of the counter will be reached before the furthest future data required. (A related issue may be that the base date, i.e. when the counter = 0, is too recent for our requirements. For example, MS-DOS that has a base date of 4 January 1980.)
Number-to-date (and vice versa) conversion algorithms do not calculate leap years correctly.

As a consequence, hardware and / or software failures may occur when a system or application date crosses to the year 2000. The types of failure that could occur include:

Incorrect computer arithmetic, comparison, sorting or sequencing operations. This could result in the failure of logical, relational and set-membership operations.
Failure to recognise the year 2000 as a leap year.
Incorrect action on the basis of the contents of date fields that are used for non-date purposes (e.g. a year of 99 means "never delete" or "end of file", or 00 means "no date provided" or "start of file", and s o on).
Date data fields could overflow.

There are two issues to be considered when discussing these failures:

What was the product designed to do?
What are the consequences of the failure?

If a product was designed to operate to a given spec, then it is up to the user to know what that spec is and to satisfy himself that this is acceptable to him.

For example, when using the "short date" form for the input of dates, (that is, "31/12/98", for example), then a product like MS Excel 97 is designed to interpret the date according to the rule that if the 2-digit year is less than 30, the century is "19" and if it is greater or equal to 30, the century is "20". If, however, the long date format is used (that is, 31/12/1998, for example), then the date is unambiguously interpreted and stored correctly. In any eve nt, because of a counter limit, the highest date that can be stored in Excel 97 (version 8) is 9999-12-31. Prior versions had a highest date of 2078. All Excel versions have been designed to accept and store an earliest date of 1900-01-01. However, even v 8 has a failure when it assumes 1900 to be a leap year. On can only assume that it makes another incorrect conversion later, since the day of week is corrected later.

The MS-DOS operating system is designed to operate correctly for all system dates between 1980-01-04 and 2099-12-31. After that, unpredictable things happen.

Since recourse is limited (most software has a limitation of liability to the cost of purchase, and that only for 60 days from date of purchase) and the user may not wish to stop using the product, the issue of consequences of failure must be raised.

For example, if a user is making use of WordPerfect 5.0 to type documents, and he can just as easily type the correct date as use the "Insert Date" function, or Lotus 123 v3 is being used to do monthly budgets, the user may choose to not do a nything with regards to the date problem that either the hardware or software has, since the function for which the technology is being used is not impaired in any significant way.

The issues then are:

Is the technology compliant?
If not, then what is the technology being used for?
Will the function to which the technology is being applied be materially affected by non-compliance? (By "material", we mean that incorrect processing will result in a loss to the enterprise. Clearly, we would need to quantify that loss.)
If so, what will it cost to fix the non-compliance? (We would like to propose a definition for "cost" which is broader than purely monetary. More significant is, "If I had to spend the money / time / effort on fixing this item, would it inhibit me from fixing something else, in time, which is more important?)

Other issues relate to the spec. If the technology was designed to operate within certain bounds (for example, up to 1999-12-31), then this may not be acceptable, and corrective action will have to be taken, although there will be not be much opportuni ty for recourse against the vendor.

The purpose of this document is to describe the levels of Y2000 compliance as they apply to the Department of Finance.

Compliance

Compliance Definition

There are a number of compliance definitions in use. They almost all agree in at least some respects, but this does lead to some confusion.

It would appear that the most widely accepted definition is the one from the British Standard Institute (accepted by 95 out of 140 countries).

The essential aspects that should be taken into account when assessing Y2000 compliance are:

The technology should not be negatively affected by dates prior to, during or after 2000.
The year 2000 should be recognised to be a leap year.
Technology should not be affected by date data that is exchanged with it.
The technology should be used in accordance with its documentation.
If there are special issues relating to the use of date data, then these should be explicitly stated in the documentation.

Levels of Compliance

At the highest level, software would be compliant in the sense that no date, past, present or future, would cause a failure in processing. In addition, dates would not be used for purposes that are not related to the calendar. ( See the Cinderella Definition It is unlikely that any technology would conform to this stringent requirement, excepting if it does not use dates at all.) Alternatively, there should be no date data in the technology whatsoever.

Level 2 would be that the technology satisfies the provisions of DISC PD2000-1.

Level 3 would be that the technology satisfies the provisions of IEEE P2000.1.

Level 4 would be that the technology would operate correctly until or after 2000-01-01.

Level 5 would be that the technology would not fail materially after 2000-01-01.

Level 6 would be that the technology would fail (but not materially) before 2000-01-01.

Level 7 would be that the technology would fail materially after 2000-01-01.

Level 8 would be that the technology would fail materially before 2000-01-01.

Certification of … What?

Obviously, we need to identify what it is that we should be investigating and making compliant, if necessary. Most definitions refer only to technology in the context of compliance. Yet, the truth is, we need to look more broadl y than technology when we are considering certification.

The following list summarises some of the issues:

Technology

Bespoke Systems (developed to the enterprise’s specification)

Internally Developed (developed internally, under enterprise control, with or without the use of external contractors)
Externally Developed (where external parties had control over developing, and may or may not have control over maintenance)
Outsourced (where an external party has full responsibility for maintenance and running)

Packages (like BAAN, SAP, BPCS, etc.)
COTS (Commercial Off The Shelf) software
Firmware (like BIOS)
Embedded Systems
Scope
Own technology (technology that is owned by, or used by the enterprise and is under its control.)
Outsourced technology (technology owned and managed by a third party that the enterprise makes use of, where there is typically not equivalent functionality in-house. For example, the function of routing cheques and related transactions may be under t he control of the ACB.)
Partners (technology that is interfaced to, usually through methods like EDI, or exchanging of magnetic media.)
Supply Chain
Suppliers (if suppliers have not fixed their critical technology, supply of critical services or goods may be disrupted, resulting in the losses to the enterprise).
Customers (if customers have not fixed their critical technology, their viability may be affected, resulting in loss of turnover or squeezed margins for the enterprise).
Partners (if the enterprise is delivering goods or services in conjunction with partners, the enterprise might be affected by the failure of the partner. Partners may include financial service providers like banks, medical aid, pension fund administra tors, trucking, etc.)
Competitors (if competitors’ ability to serve their stakeholders were to be affected this might result in exponential increases in demands on the enterprise, which it might not be able to cope with, thus resulting in impacted service levels).

Certification of Compliance

The certification of compliance involves the process that is used to ensure that technology is compliant. At the end of this process, a compliance certificate would be issued that would describe the final level of compliance. A compliance certificate is can only be valid if

The technology it applies to is unambiguously described.
The required level of compliance is stated.
The actual level of compliance is stated.
It is accompanied by a set of test criteria and test results.
It is possible to duplicate the test results.
The test criteria are comprehensive.
It has been properly authenticated.

To date, there are very few compliance certificates that would conform.

It is therefore necessary to do compliance verification by testing. Since testing can be an expensive and time-consuming task, it may be necessary to apply the Rule of Importance.

Importance

Decision-making with regards to how problems should be addressed should take into account the importance of a function, which is being supported by technology, to the enterprise. The Rule of Importance involves answers to the questions:

What would the impact be if the function being considered were to be impaired?
Just how dependent is the function on the supporting technology?
What is the compliance level of the function?

As a consequence of answering these questions, it may turn out that the technology either does not need to be compliant or a lower level of compliance is all that is required. For example, it may turn out that the technology, together with a manual wor karound is all that is needed, and no more effort need be spent on the item. The time, effort and cost can thus be put to more effective, and possibly, critical use.

The levels of importance could be described as follows:

Level	Name	Description
II00	No Functionality Impaired
II01	Individual Level Function Imp	A function at the individual level is impaired.
II02	Work Group Level Function Imp	A function at the work group level is impaired.
II03	Division Level Function Imp	A function at the divisional level is impaired.
II04	Enterprise Level Function Imp	A function at the enterprise level is impaired.
II05	Significant Cost of Failure	Failure of the function has significant cost implications.
II06	Strategy Impaired	Failure of the function can cause the ability to implement strategic initiatives to be impaired.
II07	Service Level Impacted	Failure of the function can cause the ability to maintain service levels at acceptable levels to be impaired
II08	Contravention of Law	Failure of the function could lead to contravention of the law.
II09	Going Concern Affected	Failure of the function could affect the ability to continue as a going concern.
II10	Human Misery Results	Failure of the function would lead to increase in human misery.
II11	Loss of Life	Failure of the function could lead to the loss of human life.

The level of support that the technology being evaluated provides to the function (or technology usage level) could be described as:

Level	Name	Description
CR0	Technology Adds No value	The technology adds no value to the function.
CR1	Technology Adds Little Value	The technology adds little value to the function.
CR2	Alternative Available	There is an easy to implement workaround or alternative function already in place if the technology should fail.
CR3	Workaround Easy	A workaround is possible and requires relatively little effort to implement.
CR4	Workaround Difficult	A workaround is possible but difficult and costly to implement.
CR5	Function Seriously Impaired	The function would be seriously impaired if the technology were to fail (e.g. credit card transactions could still take place via paper devices, but with severe impact, risks of fraud rise to potentially unacceptable levels).< /FONT>
CR6	Function Dependent on Techn	The function cannot be executed without the supporting technology (e.g. ATM functions cannot work without the enabling technology).

Compliance Certification Level could be described in the following way:

Level	Name	Description
L0	Retired	Technology has been retired since it was first added to inventory. All impact on other technology has been dealt with. The technology no longer exists in any working form any longer.
L1	Certified: Comprehensive Test, Audit	Technology has been certified through comprehensive testing. There are explicit test criteria and test results. The certification process ahs been verified by independent audit and the audit results have been studied and are f ound to be satisfactory.
L2	Internal Test, Defined Process	The technology has been subjected to internal testing using a defined process, which includes explicit test criteria and there are explicit test results.
L3	COTS with Compliance Stmt	COTS has a compliance statement that has been verified by an independent part. There are test criteria and test results supporting the claims made. The vendor is prepared to back this up with warranties.
L4	Vendor Tested Only	The vendor claims to have tested his software. The vendor is prepared to provide warranties.
L5	To be Retired	Technology is to be retired, switched off, removed. Related technology still needs to be modified so that any dependence is removed.
L6	Internal Test, Undefined Process	The technology has been tested internally, but there are no explicit test criteria, or the test criteria have been found to be inadequate, or there are no explicit test results, or the process used has not been explicitly docu mented, or it has been found to be inadequate.
L7	Qualified Compliance Stmt	There is a qualified compliance statement that exposes the enterprise to risk.
L8	Design Checked, No Test Done	The vendor has not tested the technology, however, there is confirmation that the design took into account any date related issues. Any issues are explicitly described in the documentation.
L9	Uncertified	The technology has not been certified as yet.

Remediation Effort

Another issue that one needs to consider when deciding what should be done, is the cost of remediation. Cost in this sense is more than money or time, and could be described as follows.

The amount of effort required to fix the problem will be considerable (can be expressed in person-hour ranges depending on the typical project that the company manages). This obviously varies as we get closer to the earliest failure date (the latest date by when changes must be implemented to prevent failure, or to manage the failures, of a CCI). The effort would be spent in fixing, replacing, developing workarounds and any other activities t o avoid or mitigate the risk of failure.

The amount of time required to fix the problem. For example, if a CCI has been created and is being maintained by a supplier, the amount of actual effort may be low, but lead times and contract negotiation time might jeopardise the implementatio n of any required fixes.

The cost of fixing the problem. Depending on the nature of, and other factors inherent in the enterprise, the cost requirement, or the cost approval process may be so long as to result in protracted negotiation before approval is obtained.

The requirement for external input. This is also a time-related aspect. If a great deal of effort is required from, or key task completion exit criteria are dependent on external parties (to the maintenance project team), this results in inevita ble delays and is notoriously difficult to manage.

There are many dependencies on other projects. This may also be true, if there are few dependencies, but the dependencies are risky (e.g. the dependent aspects of the other project may not be ready in time). One of these dependencies may be the compliance of platforms.

All of these require, potentially, a lot of work to resolve. Note: the guidelines given assume that remediation projects will commence by latest 3^rd quarter 1998!

Author: Elmar Roberg.
Business Transformation Services. PO Box 7367, Westgate 1734, South Africa.
E-mail: roberg@iafrica.com

A Definition Of Year 2000 Conformity Requirements

Introduction

This document addresses what is commonly known as Year 2000 conformity (also sometimes known as century or millennium compliance). It provides a definition of this expression and requirements that must be satisfied in equipment and products which use dates and times.

It has been prepared by British Standards Institution committee BDD/1/-/3 in response to demand from UK industry, commerce and the public sector. It is the result of work from the following bodies whose contributions are gratefully acknowledged: BT, C ap Gemini, CCTA, Coopers & Lybrand, Halberstam Elias, ICL, National Health Service, National Westminster Bank.

BSI-DISC would also like to thank the following organizations for their support and encouragement in the development of this definition: taskforce 2000, Barclays Bank, British Airways, Cambridgeshire County Council, Computer Software Services Associati on, Department of Health, Ernst & Young, Federation of Small Businesses, IBM, ICI, National Power, Paymaster Agency, Prudential Assurance, Reuters, Tesco Stores.

While every care has been taken in developing this document, the contributing organizations accept no liability for any loss or damage caused, arising directly or indirectly, in connection with reliance on its contents except to the extent that such li ability may not be excluded at law. Independent legal advice should be sought by any person or organization intending to enter into a contractual commitment relating to Year 2000 conformity requirements.

This entire document or the definition section may be freely copied provided that the text is reproduced in full, the source acknowledged and the reference number of the document is quoted.

THE DEFINITION

Year 2000 conformity shall mean that neither performance nor functionality is affected by dates prior to, during and after the year 2000.

In particular:

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 recognized as a leap year.

AMPLIFICATION OF THE DEFINITION AND RULES

General Explanation

Problems can arise from some means of representing dates in computer equipment and products and from date-logic embedded in purchased goods or services, as the year 2000 approaches and during and after that year. As a result, equipment or products , including embedded control logic, may fail completely, malfunction or cause data to be corrupted.

To avoid such problems, organizations must check, and modify if necessary, internally produced equipment and products and similarly check externally supplied equipment and products with their suppliers. The purpose of this document is to allow such ch ecks to be made on a basis of common understanding.

Where checks are made with external suppliers, care should be taken to distinguish between claims of conformity and the ability to demonstrate conformity.

Rule 1

1.1 This rule is sometimes known as general integrity.

1.2 If this requirement is satisfied, roll-over between all significant time demarcations (e.g. days, months, years, centuries) will be performed correctly.

1.3 Current date means today's date as known to the equipment or product.

Rule 2

2.1 This rule is sometimes known as date integrity.

2.2 This rule means that all equipment and products must calculate, manipulate and represent dates correctly for the purposes for which they were intended.

2.3 The meaning of functionality includes both processes and the results of those processes.

2.4 If desired, a reference point for date values and calculations may be added by organisations; e.g. as defined by the Gregorian calendar.

2.5 No equipment or product shall use particular date values for special meanings; e.g. "99" to signify "no end value" or "end of file" or "00" to mean "not applicable" or "beginning of file".

Rule 3

3.1 This rule is sometimes known as explicit/implicit century.

3.2 It covers two general approaches:

(a) explicit representation of the year in dates: e.g. by using four digits or by including a century indicator. In this case, a reference may be inserted (e.g. 4-digit years as allowed by ISO standard 8601:1988) and it may be necessary to allow for exceptions where domain-specific standards (e.g. standards relating to Electronic Data Interchange, Automatic Teller Machines or Bankers Automated Clearing Services) should have precedence.

(b) the use of inferencing rules: e.g. two-digit years with a value greater than 50 imply 19xx, those with a value equal to or less than 50 imply 20xx. Rules for century inferencing as a whole must apply to all contexts in which the date is used , although different inferencing rules may apply to different date sets.

General Notes

For Rules 1 and 2 in particular, organisations may wish to specify allowable ranges for values of current date and dates to be manipulated. The ranges may relate to one or more of the feasible life-span of equipment or products or the span of dates required to be represented by the organisation's business processes. Tests for specifically critical dates may also be added (e.g. for leap years, end of year, etc). Organisations may wish to append additional material in support of local requirements.< /P>

Where the term century is used, clear distinction should be made between the "value" denoting the century (e.g. 20th) and its representation in dates (e.g. 19xx); similarly, 21st and 20xx.

IEEE P2000.1 Draft Standard for Year 2000 Terminology

The following was extracted from the draft documentation of the above standard. According to information received, the IEEE has discontinued this project. As a consequence, the following is included as information only, since it does address some important issues.

The IEEE P2000.1 Standard for Year 2000 Terminology has the following definitions:

"Conformance

"Vendors who claim that their products conform to this standard declare that their use of the term "Year 2000 Compliant" and of defined terms within its definition are in accordance with the definitions in this standard.

"Definitions

"Year 2000 compliant: Technology is Year 2000 compliant if it is capable of accurately processing, providing, and/or receiving date data within and between the 20th and 21st centuries, provided that:

1. the technology is used in accordance with its associated documentation, and
2. all other technology used with it properly exchanges date data with it.

"Technology: Hardware, software, and firmware systems and system elements including but not limited to information technology, embedded systems, or any other electro-mechanical or processor-based systems.

"Date processing: The handling of date data within a system or system element.

"Date exchange: The interchange of date data between two or more systems or system elements. In order to facilitate proper date data exchange between two or more systems or system elements, defined formats should be identified and document ed by the suppliers of systems or system elements. Such formats may be specified by the standards or other publications listed in section 2, other generally accepted industry date representations, or other documented methods of date representation. Depe nding upon the date formats selected, additional information such as, but not limited to, valid date interval, pivot year, and encoding technique may also need to be documented."

US Government Compliance Definition

"With the issuance of the new FAR rule, agencies now have a standard definition of what constitutes "Year 2000 compliant." Development of the FAR language represented collaborative effort between the CIO Council Subcommittee, the FAR-Information Technology Committee, GSA, and industry. The Government took the lead in developing a standard definition after determining that none existed in industry. Without an acceptable definition, industry was unwilling to ide ntify which products were compliant. While seemingly a minor issue, the importance of a standard definition cannot be over emphasized. The definition sets the standard for Government-wide efforts to acquire and upgrade the Federal inventory of informati on technology. Its development represents a major breakthrough and is a vital first step in developing contractual compliance language. FAR 39.002 defines Year 2000 compliant as follows:

"Year 2000 compliant", as used in this part, means, with respect to information technology, that the information technology accurately processes date/time data (including, but not limited to, calculating, comparing and sequencing) from, into , and between the twentieth and twenty-first centuries, and the years 1999 and 2000 and leap year calculations, to the extent that other information technology, used in combination with the information technology being acquired, properly exchanges date/ti me data with it."

"Simply stated, the definition requires that Year 2000 compliant information technology products accurately process date/time information regardless of whether the date is in this century or the twenty-first, (e.g., includes any processing or use of date information including, but not limited to, such processing actions as calculating, comparing, and/or sequencing.) Additionally, it recognizes that a Year 2000 compliant product may not accurately process date/time information if it is from a non -Year 2000 compliant source.

"Without standard Year 2000 language, agencies had to develop unique solicitation and contract clauses and definitions of compliance. Agency language varied from ineffective to over demanding and impossible to perform. In some instances vendors were required to certify that not only were their products capable of meeting Year 2000 requirements, but that any information from other systems or products would also be compliant. The degree of risk the vendors were being asked to assume had a direct and predictable impact on pricing. Also, such language could actually jeopardize agency needs if it was determined that such a contract was not enforceable because the language placed impossible requirements on the contractor.

"In addition to wide variance in solicitations and contracts, considerable confusion was possible about information passed between systems. For example, with multiple definitions of the term "Year 2000 compliant" a system could be consi dered Year 2000 compliant by one agency or department but not meet stricter standards imposed by another agency. Agencies exchanging data with other government entities as well as software manufacturers were understandably concerned with having to meet w hat, quite literally, could have been hundreds of Year 2000 compliance standards.

"The final rule. Year 2000 compliance definition relieves agencies from having to develop their own definitions. Carefully crafted by Government, with significant input from industry, the new FAR definition serves as a baseline for agreeme nt on what constitutes Year 2000 compliance. This provides agencies a standard, Government and industry accepted definition of Year 2000 compliant products."

Cinderella Year 2000 Compliance Definition

Cinderella is a Year 2000 project that has been endorsed by The Computer Society of SA / Project Management Institute of SA Year 2000 Special Interest Group (Y2SASIG). For more information, visit http://www.cinderella.co.za .

This is a very stringent compliance definition, and it is unlikely that (especially older) technology will conform to it.

YEAR 2000 COMPLIANT can be stated as the attribute of a computer-based system to operate correctly, unambiguously and acceptably in storing, collating (sorting), displaying, and calculating date information within defined System and User date ranges, i ncluding leap years according to the Gregorian calendar, in a form compatible with the full ISO8601 YYYY-MM-DD form, with default installation values and error checking to specifically exclude User error, before and after the Year 2000.

To this could be added that if date data is used for purposes other than to expressly represent calendar and time information, the use of date data in this way should be expressly stated (for example, if dates were to be used in encryption or password algorithms, to identify sequence, or in hidden routines in a database management system, and so on.

YEAR 2000 READY

(1) can be stated as the attribute of a computer-based system to operate correctly and acceptably in storing, collating (sorting) and calculating dates, but where the strict "compliance" rules for display or input are relaxed to allow two digit year us age or allow ambiguity, on a descending scale of Acceptability from 2 to 8, or where User procedural action or Setup is required to allow correct operation.(Cinderella)

(2) The capability of a Product, when used in accordance with its associated documentation, to correctly process, provide and/or receive date data within and between the 20th and 21st centuries, provided that all products (for example, hardware, softwa re, and firmware) used with the Product properly exchange accurate date data with it. (IBM)

(3) An organisation is Year 2000 Compliant if the performance of its systems is unaffected by dates before, during and after the year 2000.