DISC PD2000-4 Guidance and Information on PD2000-1:1998
A Definition of Year 2000 Conformity requirements

DISC Logo EIIF Logo

DISC is a part of the British Standards Institution ISBN 0580307573
BSI 389 Chiswick High Road London W44AL
Tel : +44(0)1819969000
© British Standards Institution & Electronics and Information Industries Forum 1998

This document has been jointly prepared by the BSI DISC committee BDD/1/3 and the Electronics Industries Information Forum, EIIF. All parties undertake through further liaison to:

- aid enquirers to understand the text;
- present to BDD/1/3 any queries on interpretation, or proposals for change, and keep United Kingdom interests informed;
- monitor related international, European and other national developments and promulgate them in the United Kingdom

DISC has been set up within the British Standards Institution with the support of industry and government.

Its mission is:
to help Enterprises achieve their operational effectiveness by accelerating standardization in information systems and by promoting standards and making them easier to exploit.

And its aims are:

To make an effective contribution to internationalization:
To establish an effective industry forum;
To provide the information needed to exploit standards, whether from de jure or de facto sources;

To ensure a capable standardization process;
To develop standards for quality of IT and quality of use of IT, and to be the centre for UK exploitation;
To provide a high quality of service to industry to make standards.

The Electronics and Information Industries Forum (EIIF) has been established by the FEI (Federation of the Electronics Industry) and the CSSA (Computer Services and Software Association) to represent the interests of the electronics, computer, software, telecommunications, information and associated service industries - the sectors which are expected to be the world's largest industrial group by the year 2000.

This entire document may be freely copied provided that the text is reproduced in full, the source acknowledged and the reference number of this document is quoted. Request for partial reproduction should be addressed to the BSI Copyright Manager. References to "PD2000-4" shall be interpreted as meaning this entire document.

NOTE. International and European Standards, as well as overseas standards and other DISC publications, are available from BSI Customer Services, 389 Chiswick High Road, London W4 4AL

Contents

1 Foreword
2 Disclaimer
3 Introduction
4 What does PD2000-1:1998 address and how does it help?
5 How should I use PD2000-1?
6 What else do I need to know?
7 References, acknowledgements, and sources of further information
10 Annex A Frequently asked questions

1 Foreword

BSI DISC originally published PD2000-1 in January 1997 and it has been widely adopted. The EIIF made representations to the committee (BDD/1/3) about how PD2000-1, A Definition of Year 2000 Conformity Requirements, was being interpreted and used in practice. BDD/1/3 reviewed the suggestions from the EIIF and from other sources, with the review process also meeting its duty of care placed upon it by BS 0:1997 [1].

The committee considered that amendments to the fundamental conformity requirements were neither necessary nor desirable and decided to make no change to the Definition and the four Rules. The committee accepted the representations of the EIIF and deci ded that incorporation of the EIIF proposals in the Amplification section would add value to the document and aid its interpretation. The committee also considered that further information and guidance on how PD2000-1 was being applied would be of benefit. However, they considered that it was important for PD2000-1 to remain as a single sheet publication for ease of use and reference . The addition of further information would mean an expansion of the document. Thus, an undertaking to produce this additional document was given in the revised PD2000-1:1998 which was published in July 1998. Familiarity with PD2000-1:1998 is a pre-requis ite for considering this document.

It was stated in PD2000-1:1998 that the title of this document would be "PD2000-1 in Action". However, upon reflection after the publication of PD2000-1:1998, the committee decided that the present title would be more appropriate. As the title suggests, this document provides additional information and is deliberately written in an informal manner. None of the content of this document is prescriptive, and one aim is to make it easier for users to understand when they need professional advice, and what sources of such advice might be appropriate.

2 Disclaimer

Whilst every care has been taken by BSI DISC and the EIIF in developing this document, neither the individual members nor either organization accept any liability for any loss or damage caused, arising d irectly 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 organization intending to enter into a contractual commitme nt relating to Year 2000 Conformity requirements or Compliance or Readiness.

3 Introduction

The Century Date Change or Year 2000 problem has received a lot of attention from the media, the United Kingdom Government, and from both suppliers and purchasers. Users want an assurance that items purc hased or to be purchased are unaffected by the so-called "Millennium bug". Such assurance can range from a simple statement to a detailed contractual warranty.

The publication by BSI DISC [2] of PD2000-1 in January 1997 was an important step forward especially since it was made freely available and many organizations in the UK and elsewhere have chosen to use it as their conformity definition. A new edition (PD2000-1:1998) was published in August 1998 because experience in a number of live projects since January 1997 showed that there are a number of scenarios and applications where clarification was needed of the original explanations and r ules in PD2000-1 even though the definitions (rules) remain valid.

This document, PD2000-4, is intended to give further information on PD2000-1 and guidance on its use. It has been prepared by the BSI Committee BDD/1/3 in the light of input received from a number of organizations working in this field and is jointly p ublished by BSI DISC and the EIIF (Electronics and Information Industries Forum).

4 What does PD2000-1:1998 address and how does it help?

4.1 Background

PD2000-1:1998 is based on the premise that in principle all dates are "equal" and no date, or dates, should be considered differently from any other(s). It should not matter whether a particular date is before, in or beyond 2000. If a system works today the same way as it did yesterday and the day before that etc. then it ought to work in the same way on 1 January 2000 or other critical dates (1) and beyond. Similarly, if a system is currently able to work with dates (or date related data) then it should not make any difference whether any of those dates fall before or after 1 January 2000.

(1) See Frequently asked questions - Question 13

4.2 The Four Rules

The four rules of the definition are intended to reflect the principal ways in which system operation may be affected as a result of a date-related problem. The following comments may be helpful when applying the Rules to specific situations.

4.2.1 Rule 1

"No value for current date will cause any interruption in operation." No system with knowledge of dates can operate on an infinite range of dates and every such system is therefore subject to some ultimate date limitations. The use of the term "no value" in the rule is intende d to mean that the system will operate on all dates upon which it is intended to be operated. If conformity is being claimed on a contractual, representative or other legally binding basis the actual date range over which the system is to be operated should be documented (see amplification 4.1).

4.2.2 Rule 2

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

Regardless of the date upon which the system is operating, the operation of the system may be adversely affected by date data with values which are incorrectly processed. Operations involving calculations of time duration or sequencing of date values may, for example, fail if one date is pre-2000 and the other post-1999. Rule 2 is intended to protect against problems of this nature. See also Frequently asked questions - Question 3 in Annex A.

4.2.3 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."

Ambiguity introduces a risk that an incorrect assumption or interpretation will be applied to an abbreviated date representation. If two systems or system components interpret a date in different ways then t he inconsistency is likely to result in incorrect processing or system failure. Rule 3 ensures that there is a common understanding of the significant components of a date representation wherever date information passes across a system interface or boundary.

Where inferencing rules are used and differing rules are employed, correct interpretation on both sides of the interface will be obtained only for a subset of the possible date values (i.e., if two different date windows are used, the valid window as a whole will be restricted to the range of dates with common interpretations on both sides of the interface). Any resulting limitation on the valid range of dates should be documented as it may contribute to the valid date range of the system (see amplification 4.1).

The inclusion of code to perform the processing of date inferencing rules (see amplification 3.3.2(b)) may introduce differences in the time taken to process different dates. Such differences will usually be "immeasurably small in the context of use" ( see amplification 2.2) and will therefore not make the system non-conformant unless they have an impact on the cost of use or cause the system to fail to meet a specified performance (e.g. hard real time) requirement.

4.2.4 Rule 4

"Year 2000 must be recognized as a leap year."

Although centennial dates are not normally leap years, the year 2000 is an exception and some systems may fail to recognise it as a leap year. The problem can manifest itself on or around 29 February 2000 with respect to the correct calculation of the month, day of the month or day of the week; and also on or around 31 December 2000 if it is not recognised that the year 2000 has 366 days. Strictly speaking, the requirements of this rule will be met if the first three rules are obeyed. However, there is sufficient misunderstanding and confusion to warrant the inclusion of this explicit requirement.

4.3 "Comply" and "Conform"

The terms "comply" and "conform" are often used interchangeably. However, BSI has a set of rules, defined in a document numbered BS 0, for terms used in standards making. In BS 0-3:1997, A standard for standards — Part 3: Specification for structure, drafting and presentation [1], it says:

6.3.6 Use of "comply" and "conform"

The wording "conform to" shall be used in provisions that require a characteristic of a product, material, process, service or system to be in accordance with a standard or its requirements. The wording "com ply with" shall be used in provisions that relate to the action of a person or an organization in enabling conformity to be achieved.

NOTE. Conformity of a characteristic of a product, material, process, service or system with a standard or its requirements results from compliance by a person or an organization with the standard or its requirements

4.4 Year 2000 Conformity, Compliance, Compatible, and Ready

Phrases such as "Year 2000 Conformant", "Year 2000 Compliant", "Year 2000 Compatible" and "Year 2000 Ready" have no clear meaning unless a specific definition is also mentioned. Many organizations are defining these terms to suit their own purposes (which may be entirely proper) but users should ensure that the specific definition is clearly understood before relying on them. The best way to declare that a product or item of equipment meets the requirements of PD2000-1:1998 is to say that it "conforms to DISC PD2000-1:1998".

4.5 Definition vs. Warranty

PD2000-1:1998 is not a warranty statement or wording. It is a Definition of Year 2000 Conformity which in turn may be the subject of a warranty. Where the definition is used (or called up by reference) in contracts then the definition needs to be used in a sentence in a contract which deals clearly with the Year 2000 issue and nothing else. Any warranty clause should be reviewed carefully against the needs of the project rather than being a universal clause. Over-specifying the requirement can be as unhelpful as under-specifying it.

5 How should I use PD2000-1:1998?

5.1 Status / Position of PD2000-1:1998

PD2000-1:1998 provides a definition on which to base discussions about Year 2000 conformity. It is intended as a basis for clear communication between interested parties who will also need to know much more about the system(s) of interest and the scenario(s) in which they operate. It is not intended as a weapon nor as a prescriptive basis for dealing with the Year 2000 issue. It is important to review all associated documentation before attempting to apply the Definition and Rules. In many cases there will be domain-specific standards (2) which define inter-working between various parts of a system, and these standards may have evolved over a period of time. Some of the constraints and approaches represented by the standards may be present for sound practical reasons, and some may be outdated strategies which need not be preserved (and which might even be the cause of real problems in the context of Year 2000 issues). Distinguishing between the two cases requires real understanding and intelligent thought, rather than superficial surface- skimming or attempts to apply "solutions" without understanding the relevance of the proposed solutions.

(2) These may be formal standards published by a standards body, or industry standards defined by one or more manufacturers or users, or common practi ces.

5.2 Complexityof Issue / Scope of Project or Contract

Conformity is a complex issue and it can be achieved in many different ways. There is no universal solution. That makes it important to establish the basis for any claim of conformity. There are major differences between the supply of customised or bespoke systems, COTS (Commercial Off The Shelf) sometimes also known as "shrink-wrapped" software such as word processors or spreadsheet packages, and equipment with embedded devices or firmware. All may have differing requirements for use and hence require different appro aches when assessing their conformity.

With software particularly, much more information than that the software is "Year 2000 conformant" will be needed. Very little software operates in complete isolation, so there are likely to be interfaces to other parts of the overall system. Knowledge of the techniques used to ensure conformity of the software to PD2000-1:1998 may be required (e.g. if "windowing" has been used, what are the pivot dates? etc.). The need for any date validation varies widely with the nature of the system and the interface (e.g. user input, data transmission, file storage, etc.). Another important distinction is between systems operating in real-time and systems processing historical data. Real-time systems such as telecommunications systems and electronic funds transfer or banking operate with data which is usually less than 3 days old. This should be contrasted with systems such as payroll where employee or pensioner dates of birth will exist (in the past), or mortgage and loan systems where maturity dates exist in the future. Archiving needs to be considered carefully, especially for systems using restricted date fields. In its original context or application a restricted date field might be completely unambiguous, but if archived without also archiving a definition of the original scenario, such a restricted date field could become ambiguous.

Provision can be made for software or a system which will not initially meet the requirements of Year 2000 Conformity but will do so in due course. It will often be important to distinguish the Year 2000 Conformity of any software or system being delivered from the Year 2000 Conformity of existing software and systems with which the new products will interact. It may be appropriate that the commitment as to Year 2000 Conformity should relate only to the delivered items in so far as they are not affected by other items.

5.3 System issues and Inter-working

The fundamental question of interoperability with other components such as legacy systems or any third-party system also needs attention. In general, this is a systems integration task and it is importan t that an overall owner be identified right from the start. If this is not done then there is a risk that systems which are individually conformant may still not interwork correctly. If another supplier claims that his system is compatible with the system in question, then in general it will be that supplier's responsibility to achieve that compatibility.

6 What else do I need to know?

6.1 Use of Additional Material

It should be recognised that it is very difficult to write a Conformity Definition that could possibly address all facets of all situations. This is recognised in 4.2 of the Amplification where it states "Organizations may wish to append additional material in support of local requirements". However, experience has shown to date that some users are reluctant to add additional material, even to the extent of being suspicious of such material pro posed by potential parties to a contract. Naturally it would be prudent to examine any such proposal carefully in the context of the specific project(s) concerned, but the flexibility offered by this method could prove a valuable way of accommodating specific project needs without compromising the basic principles of Year 2000 Conformity.

6.2 Assessing Your Business Risks

Reference to the guidance in BSI DISC PD2000-2, Managing Year 2000 Conformity: A Code of Practice for Small and Medium Enterprises, or other appropriate publications, can help you assess the particular risks from the Year 2000 problem to your business and help identify your needs to address those risks. Only you can do that - it is your business: you are the one who knows most about it. When you have identified what you need to do, then you can obtain he lp from the right quarter and you will be better able to agree terms and statements with your supplier(s).

7 References, acknowledgements, and sources of further information

7.1 References

[1] BS 0:1997 A standard for standards Available from BSI Customer Services on +44 (0)181 996 7000
[2] BSI DISC, 389 Chiswick High Road, London W4 4AL, UK.
PD2000-1:1998 A Definition of Year 2000 Conformity Requirements
PD2000-3 Understanding the Century Date-Change Problem
PD2000-4 Guidance and Information on PD2000-1:1998 available from: http://www.bsi.org.uk/disc/year2000.html/
PD2000-2 Managing Year 2000 Conformity: A Code of Practice for Small and Medium Enterprises
Available from BSI Customer Services on +44 (0)181 996 7000
[3] BS EN 28601 Specification for representation of dates and times in information interchange
Available from BSI Customer Services on +44 (0)181 996 7000

7.2 Acknowledgements

The following organizations contributed to the development of this document: Action 2000
Halberstam Elias
BT plc ICL
CCTA
National Health Service
Cap Gemini UK plc
Nat West Plc
Digital Equipment
PricewaterhouseCoopers
EIIF
Taskforce 2000

7.3 Sources of Further Information

Action 2000 Web Page http://www.open.gov.uk/bug2000.htm/BR> BSI DISC Web Page http://www.bsi.org.uk/disc/year2000.html/
CSSA Web Page http://www.cssa.co.uk/cssa/new/millen.htm/
CCTA Web Page http://www.open.gov.uk/ccta/mill/mbhome.htm/
IEE Web Page http://www.iee.org.uk/2000risk/
IEEE (USA) Web Page http://computer.org/standard/P2000web/index.htm/
Taskforce 2000 Web Page http://www.taskforce2000.co.uk/

ANNEX A

Frequently Asked Questions

General Note
The questions and answers apply to both PD2000-1:1998 and the original PD2000-1 unless otherwise stated. For brevity, the reference "PD2000-1" is used unless the full reference is essential for accuracy.

Q1 What is the difference between conformant and compliant?

A1 The formal International Standards community have an internal convention, which distinguishes between the two. In practice most people use "conform to DISC PD2000-1:1998" and "comply with DISC PD2000-1:1998" interchangeably though the first is preferred and recommended. The important point though is to mention PD2000-1:1998 in any conformity (or compliance) claim. On their own, "Year 2000 conformant" (or "Year 2000 compliant") are meaningless terms. See also BS 0: Part 3 paragraph 6.3.6 [1] cited in section 4.3.

Q2 What is "Year 2000 Ready"?

A2 This expression has no meaning in the context of PD2000-1 because its interpretation varies widely. The recommendation is to avoid use of this expression in general, unless its meaning is clearly defined in the context in which it is used.

Q3 I've noticed the rules don't say anything about having to work correctly. Why not?

A3 It is not necessary for PD2000-1 to state explicitly that a system should work correctly. The reason is that if a system works correctly now, and if it satisfies the definitions in PD2000-1 then it wi ll work correctly with dates in 2000 and beyond. If the system does not work correctly in the first place, that is nothing to do with Year 2000 and is a completely separate matter. The other reason for not using such terminology in the rules is that it would leave them open to interpretation. Some people might view correct operation differently from others.

Q4 How can a supplier claim a product is conformant if the performance is different from an earlier version?

A4 PD2000-1 is concerned only with the use and handling of different dates within a single product or item of equipment. If a system worked a certain way yesterday and today, users also want it to work t hat way in 2000 and beyond. If their current system cannot work in 2000 or beyond then they need to get it fixed or changed. Once they get the fixed version, it is a different one from the point of view of PD2000-1. What conformity to PD2000-1 ensures is that, for example, once 2000 is reached a particular system does not suddenly change its performance compared with how it was working in the last few days of 1999. This issue is clarified i n PD2000-1:1998 but it is important to realise that the requirement is the same in both PD2000-1 and PD2000-1:1998. The performance or functionality of a system frequently changes between versions or releases. Whether that is acceptable or not is a separate matter which frequently arises but it is not an issue specific to year 2000.

Q5 Rule 2 refers to "dates prior to, during and after year 2000". Does this mean systems have to work forever?

A5 No. PD2000-1 is intended to have widespread application. It cannot, and should not, define the dates that are valid for any particular system. It is, however, highly advisable that any conformity declaration documents state the range of dates for which the system delivers conformant performance (see also the General Notes at the end of PD2000-1).

Q6 The software licence for my system is an annual licence and expires at the end of each year. How is this dealt with in PD2000-1 ?

A6 This point is covered by Rule 2 which requires consistent behaviour prior to, during, and after the year 2000. If the software licence expires annually and continues to do so then this is nothing to d o with year 2000 issues.

Q7 How do I know what the performance and functionality should be ?

A7 In general, any performance or functionality requirement should refer back to the Technical Specification (or other appropriate document). This enables the important principle of Year 2000 Conformity to be separated from technical detail which will vary from case to case (or may vary during the life of a contract). In the absence of a formal specification, parties to contracts will have to agree how to verify that Conformity has been achieved.

Q8 Does PD2000-1 insist on a 4-digit year?

A8 No. The objective of PD2000-1 is that systems work correctly, not that any particular solution be applied. There are many systems which operate with restricted ranges of possible date data values and where changes to the date format are both unnecessary and disruptive. This is why it is so important to review all of the relevant documentation before attempting to apply the Definition and Rules, as discussed in paragraph 5.1 of this document.

Is the year 2000 in the 20th century or 21st century? PD2000-1 does not say.

A9 Strictly speaking, the year 2000 is at the end of the 20th century because we will not have completed 2000 years until the end of 2000. However, for all practical purposes, it is being treated as 21st century (i.e. the two digits denoting the century part of the 4-digit year change on 01/01/2000).

Q10 Why is PD2000-1 a ‘Published Document' (PD) and not a British Standard (BS)?

A10 When BSI DISC started work on the Year 2000 issue in late 1996, there was user demand for sound guidance in a rapid time scale commensurate with the speed of growth of understanding about the scale a nd nature of potential problems. The preparation of a formal British Standard (BS) can be a lengthy process and in the interests of expediency it was decided to produce a Published Document (PD) instead. This is allowed under BSI's rules (contained in BS 0:1997 [1]) but it should be understood that a PD does not have the full status of a BS. Nevertheless, it is evident that PD2000-1 has widespread acceptance and thus could be regarded as a de facto standard.

Q11 Rule 3 of the Definition Section of PD2000-1 uses the words "inferencing rules". Why isn't "inferencing" in my dictionary?

A11 "Inferencing" is a piece of jargon which means a rule that draws upon an inference. An example of such a rule might be for a system which uses 2 digits to represent the year. Thus, 50 and g reater infer the years 1950 to 1999 whilst numbers less than 50 infer the years 2000 to 2049. PD2000-2 "Managing Year 2000 Conformity Requirements: A Code of Practice for Small and Medium Enterprises" gives a fuller explanation of such ‘inferencing r ules' in the context of Year 2000.

Q12 Is the year 2000 a leap year?

A12 Most definitely, yes. This was foreseen as long ago as the 16th Century by Pope Gregory XIII who proclaimed the calendar used in the western world and in nearly all computer systems today. BS EN 2860 1 [3] defines a leap year according to Pope Gregory's rules as follows:
"year, leap: In the Gregorian calendar, a year which has 366 days. A leap year is a year whose number is divisible by four an integral number of times, except that if it is a centennial year it shall be divisible by four hundred an integral number of times."
Thus 2000 is a leap year, and will have a 29 th day of February, but 1900 was not a leap year.

Q13 What about "critical dates" other than 1 January 2000 which are related to the Year 2000 problem?

A13 As mentioned above you should ensure that your systems can deal with 29 February 2000. It has also been suggested that the date 9 September 1999 can cause problems, since it may have been stored as 9 /9/99 and a sequence such as this is sometimes used in date fields to represent dates which can never be exceeded or ‘End of File'. These might cause problems in many different ways during 1999 or at any time in the future. Another date which may cause pr oblems is 31 st December 2000 because it is the 366 th day of the year, and in previous leap years some systems have failed when this date was encountered.

PD2000-2 "Managing Year 2000 Conformity Requirements - A Code of Practice for Small and Medium Enterprises" gives a fuller explanation of dates that might cause problems.

Also, the Institution of Electrical Engineers (PO BOX 96, Stevenage HERTS SG1 2SD, United Kingdom tel: +44 (0) 1438 313311) produces a long list of dates in its publication "Embedded Systems and the Year 2000 Problem, Guidance Notes" (IEE Technical Guidelines 9:1997, also available from http://www.iee.org.uk/2000risk/.)