Criteria for Century Compliance

Year 2000 Compliance

This document presents an interpretation of the Year 2000 definition prepared by the British Standards Institution (BSI) "DISC PD2000-1 A Definition of Year 2000 Conformity Requirements". It provides information regarding the scope of the problem and discusses the four criteria outlined in the BSI definition.

Copyright ©1998 Content Technologies Ltd. All rights reserved

Revision 1.0

Disclaimer
Information contained in this document is the commercial property of Content Technologies Ltd and is not to be disclosed to any third party without explicit permission of Content Technologies Ltd.
MIMEsweeper is a trademark of Content Technologies Ltd. Trademarks of other companies are used for descriptive purposes only and are fully acknowledged.

Introduction


Century compliance

Year 2000 compliant is a term commonly used in the IT industry to emphasise the importance of the year 2000 deadline and the problems associated with that single event. However, this document uses the term, century compliant, to emphasise the broader aspect of the year 2000 compliance problem.

Background

Century compliance means that computer systems and software are designed and tested to correctly interpret and process data that represents the calendar year 2000 and beyond. Condensing the number of digits that represent a calendar year from four digits to two ("1997" is represented as "97", for example) is a convention originally meant to save keystrokes and computer storage. However, many computer programs regard all years as belonging in the same century. They interpret "00" as "1900" even if the intended year is "2000" This false interpretation produces incorrect calculations and may cause system outages. All computer systems must be specifically programmed for Year 2000 recognition.

Statement of intent

Content Technologies will enforce Year 2000 compliance in all new and existing mission critical systems by using the criteria defined in this document.

Software products produced by Content Technologies will be examined and tested for year 2000 compliance in as far as this is reasonably possible. Any discrepancies found will either be resolved, or clearly documented with the reasons for retaining the current format.

It will be assumed that any software product produced by Content Technologies is running on year 2000 compliant hardware, and operating system. This may require the mandatory addition of service packs to some versions of the operating system.


Criteria for century compliance


This proposal for century compliance requires that software satisfy four, date-related criteria. Software meeting all four can be considered century-compliant. These criteria are taken from the BSI document DISC PD2000-1 and listed in Table 1.

Criterion

Description

General integrity

No value for current date will cause interruptions in normal operation.

Date integrity

All manipulations of calendar-related data (dates, durations, days of week, etc.) will produce desired results for all valid date values within the application domain.

Explicit century

Date elements in interfaces and data storage permit specifying century to eliminate date ambiguity.

Implicit century

For any date element represented without century, the correct century is unambiguous for all manipulations involving that element.

Table 1. Criteria for Century Compliance.

Each criterion serves as a high-level requirement for software. The following discussion elaborates on each:

General integrity

As a system date advances normally on a host processor, each date rollover must not lead either the host process or any software executing there to erroneous processing. The best-recognised high-risk date change is the rollover to 2000.

Date integrity

This criterion primarily covers the correctness of manipulations of date data. These manipulations need to be reliable only over the range of dates that an application is expected to handle. For example, sales-order processing may handle dates from 5 years in the past to one year in the future. In contrast, an employee database may store dates of birth from early in the 20th century to planned retirement dates well into the 21st century.

Explicit century

This criterion essentially requires the capability to store explicit values for century. For example, third-party products that can use a 4-digit year in all date data elements stored and passed across each interface (including the user interface) would satisfy this criterion. A base-and-offset representation of dates that covers all centuries of interest would also satisfy this criterion. Whether this capability should be used to eliminate century ambiguity is part of the last criterion.

Implicit century

This last criterion requires that, if the century is not explicitly provided, its value can be correctly inferred with 100% accuracy from the value of date provided. For example, the range of values for an "invoice date" would very rarely span more than 10 years. Since the century can always be guessed correctly for an invoice date with a 2-digit year, this date data element would satisfy this criterion.

BSI document DISC PD2000-1 provides a simple rule for inferring the correct century value. That is, two-digit years with a value greater than 50 imply 19xx, those with a value equal to or less than 50 imply 20xx.


Interpretation of the criteria


Although the four criteria fully define century compliance, it is necessary to document and distribute the interpretation within an organisation to ensure that "century compliance" is interpreted consistently.

General integrity

No value for current date will cause interruptions in normal operation.

The General Notes section of BSI document PD2000-1 allows organisations to specify the allowable ranges for values of current date and dates to be manipulated. Therefore, our allowable date range for all software on all platforms will function correctly for all values of system date between 1985-01-01 and 2035-12-31.

Of special interest are the following dates and the ability to roll over to the correct next date: 1998-12-31, 1999-09-09, 1999-12-31, 2000-01-01, 2000-02-28, 2000-02-29, 2000-03-01, 2000-12-31, 2001-01-01, 2027-12-31.

Appendix B, describes the significance of these critical test dates.

Date integrity

All manipulations of calendar-related data (dates, durations, days of week, etc.) will produce desired results for all valid date values within the application domain.

All date values and calculations are based on the Gregorian calendar as defined in Encyclopedia Britannica, 15th edition, 1994, p. 430.

Computing assets must correctly handle all representation and manipulation of dates with values between 1900-01-01 and 2050-12-31. Especially important is that all years in this 150-year range divisible by 4 are leap years except 1900.

All software developed must either initialise all date elements with all zeros (0000-00-00) or null values. Null values are defined for each application by the development facilities, such as language compiler. A null-value feature is strongly recommended in third-party-software selection.

All developed software must not contain literals or constants for dates unless required to capture specific business rules such as calculations of payroll deductions.

All developed software must not use special date values as logical flags, such as "99" as year to mean "no end date" or "00" to mean "does not apply."

Explicit century

Date elements in interfaces and data storage permit specifying century to eliminate date ambiguity.

All developed and third party software must permit the use of date formats, which explicitly specify century in all date data stored or transmitted.

All developed applications using third party products must always explicitly supply century and never rely on those products' default value for century.

Implicit century

For any date element represented without century, the correct century is unambiguous for all manipulations involving that element.

Century must be explicit in all date data stored or transmitted unless the correct century can be inferred with 100% accuracy based on the value for date. Explicit century is preferred where practical.

Developed and third party software may imply century in the user interface in the format, YYMMDD.


References


1. DISC PD2000-1, A Definition of Year 2000 Conformity Requirements, DISC is a part of the British Standards Institution, BSI, 389 Chiswick High Road, London W4 4AL.
2. GTE Government Systems Corporation, Proposed Criteria for Century Compliance:
http://www.gte.com.
3. De Jager Peter. You've Got To Be Kidding! In paper archives at:
http://www.year2000.com.
4. De Jager Peter. Doomsday. In paper archives at:
http://www.year2000.com.
5. Furman Jeff, Marotta Albert. Year 2000 - Not Just For Applications. In paper archives at:
http://www.year2000.com.
6. The Internet newsgroup, comp.software.year-2000.
7. The Internet newsgroup, comp.software.testing.
8. The Year 2000 Archive:
http://www.year2000.com.


Appendix A - BSI PD2000-1


BSI DISC PD2000-1 "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 that 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, Cap Gemini, CCTA, Coopers & Lybrand, Halberstam Elias, ICL, National Health Service, National Westminster Bank.

BSI-DISC would also like to thank the following organisations for their support and encouragement in the development of this definition taskforce 2000, Barclays Bank, British Airways, Cambridgeshire County Council, Computer Software Services Association, 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 organisations 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 liability may not be excluded at law. Independent legal advice should be sought by any person or organisation intending to enter a contractual commitment relating to Year 2000 conformity requirements.

This entire document or the definition section may be freely copied if 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 recognised 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. Consequently, equipment or products, including embedded control logic, may fail completely, malfunction or cause data to be corrupted.

To avoid such problems, organisations 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 checks 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

This rule is sometimes known as general integrity.

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

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

Rule 2

This rule is sometimes known as date integrity.

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

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

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

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

This rule is sometimes known as explicit/implicit century. It covers two general approaches:

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.

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.

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.


Appendix B - Critical date values for Year 2000 testing


The following critical dates should be tested for proper operation (i.e. the ability to roll over to the correct next date):

Date

Description

1998-12-31

Existing functionality unchanged.

1999-09-09

First time 9/9/99 is encountered (default "nonsense" date in many systems).

1999-12-31

Basic Y2K transition (Millennium transition). Sometimes used as "Never Expires" date in many systems and most likely to cause catastrophic failures.

2000-01-01

Start of year 2000. Saturday. One year to third millennium and 21st century.

2000-02-28

The Year 2000 is a leap year. This transition must be examined to determine that leap year calculations are correct.

2000-02-29

The Year 2000 is a leap year. The "leap day" transition must be examined to determine that leap year calculations are correct.

2000-03-01

Checks that day-of-week calculations are correct. Some leap year errors may not have shown on previous day.

2000-12-31

366th day-of-year, change over from 00 to 01.

2001-01-01

Third Millennium and start of 21st Century. (Monday), to check that 2000 is handled as 366 days long.

2027-12-31

1900 + a short integer year overflow error.



msw.support@mimesweeper.com
Copyright © 1998, Content Technologies Limited. All rights reserved.