DISC PD2000-4 Guidance and Information on
A Definition of Year 2000 Conformity requirements
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
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
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
To establish an effective
To provide the information needed
to exploit standards, whether from de jure or
de facto sources;
To ensure a capable standardization process;
develop standards for quality of IT and quality of use
of IT, and to be the centre for UK exploitation;
provide a high quality of service to industry to make
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
4 What does PD2000-1:1998 address and how does it
5 How should I use PD2000-1?
6 What else do I need to know?
7 References, acknowledgements, and sources of further
10 Annex A Frequently asked questions
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
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
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.
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.
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  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
4 What does PD2000-1:1998 address and how does it help?
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
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
(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
4.2.2 Rule 2
"Date-based functionality must behave
consistently for dates prior to, during and after year
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
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."
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
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)
4.2.4 Rule 4
2000 must be recognized as a leap year."
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
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 , it says:
6.3.6 Use of "comply" and "conform"
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
4.4 Year 2000 Conformity, Compliance, Compatible,
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
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
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
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.
These may be formal standards published by a standards body, or industry standards defined by one or more manufacturers or users, or common practi
5.2 Complexityof Issue / Scope of Project or
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
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
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
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
 BS 0:1997 A standard for standards
Available from BSI Customer Services on +44 (0)181 996
 BSI DISC, 389 Chiswick High Road, London W4 4AL,
PD2000-1:1998 A Definition of Year 2000 Conformity
PD2000-3 Understanding the Century Date-Change
PD2000-4 Guidance and Information on PD2000-1:1998
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
 BS EN 28601 Specification for representation of dates and times in
Available from BSI Customer Services on +44 (0)181 996
The following organizations contributed to the development of this document:
BT plc ICL
National Health Service
Cap Gemini UK plc
Nat West Plc
7.3 Sources of Further Information
Action 2000 Web Page http://www.open.gov.uk/bug2000.htm/BR> BSI DISC Web Page
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/
Frequently Asked Questions
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  cited in section 4.3.
Q2 What is "Year 2000 Ready"?
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
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
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
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
Q8 Does PD2000-1 insist on a 4-digit year?
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
Is the year 2000 in the 20th century or 21st
century? PD2000-1 does not say.
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 ) 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?
"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 
defines a leap year according to Pope Gregory's rules
"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
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
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
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