Heiko Holtkamp, Peter B. Ladkin
"Houston, we have a problem."
We describe the Year 2000 problem (the millennium bug, Y2K), what can be done about it, and what systems it is likely to affect. These pages are intended for novices as well as experts, with short descriptions of the computer-technical background linked where necessary.
These pages accompany the Bielefeld seminar "Das Y2K-Problem". We are reviewing and developing strategies for handling the Year 2000 problem. We shall be continuing to build these pages.
Back to Contents
What is the Year 2000 problem?
The Year 2000 problem arises from representing years in dates with only
two digits: 27.04.98 instead of 27.04.1998. This leads to date ambiguity:
is 01.01.00 the 1st January 1900, or the 1st January 2000? People using
such date representations usually have no problem with this ambiguity,
since one usually
has enough background information to figure out which is meant.
However, it is a problem for Computer programs, chips and other
digital hardware that have not been specifically designed to handle
this ambiguity, because computer systems work rigidly - they can't
use `background information' or identify `ambiguity', unless
this is specifically built in to their design.
A more precise description of the problem is that it is one example of a date representation discontinuity (DRD). The features of a DRD are that
A DRD is an example of a data discontinuity problem, itself in turn an example of data ambiguity problem. Such problems are a consequence of how data are represented by computers. Those who don't know may consult our gentle introduction to Data Representation in Computers.
Back to Contents
Other Date Representation Discontinuity
The Year 2000 problem is not the only DRD problem we need to worry about now.
Many computer systems (software and hardware) will have problems earlier.
Ambiguous End-of-File Markers
For example many financial and adminstrative software, especially databases,
use a date of 9.9.99 (or similar constructs such as 1.1.11, 99.99.99, 00.00.00)
as end-of-file markers. This is a particularly clear example
of data ambiguity being deliberately designed in,
when it could have been avoided.
Such systems could have problems handling dates of 9th
32-bit Unix and C
Many Unix systems (the 32-bit ones in particular) have a DRD on
19th January 2038 when the internal time representation reaches its
limit and `rolls over'.
UNIX calculates dates using the number of seconds since
1.1.1970 0:00:00 Coordinated Universal Time (Greenwich Mean Time).
This is stored as a 32-Bit signed integer, that will reach its
maximum possible value (31 1's) on 19.01.2038 and `roll over' (to
31 0's). This issus also concerns many C and C++ programs, which
use the same date representation.
GPS, the global satellite navigation system
Navigation is increasingly dependent on a satellite data system run by the
United States armed forces, known as the Global Positioning System (GPS).
A GPS system uses data from a number of satellites it can `see' in the
sky to determine precisely where it is. It is extensively used by
trucking companies to tell where their trucks are, by automobiles for
`moving map' displays showing the car's position, and of course by
aircraft to determine position. It is also increasingly used by
commercial aircraft as a primary means of navigation when approaching
to land at an airport in `instrument conditions' (when the airport cannot
be seen, or only sporadically, because of clouds, darkness or both).
Because ensuring clearance between the aircraft and earth-based obstacles
or mountains is essential `on approach', a GPS date discontinuity could
have safety-critical consequences.
GPS counts dates by counting weeks since the 5 January 1980, and stores this count in a 10-bit unsigned integer. That entails a date discontinuity between week 1024 and week 1025 since 5 Jan 1980, which will happen on 21 August 1999 (apparently at 23:59:47). GPS equipment that does not specifically handle this discontinuity may have problems at that time.
Back to Contents
Leap Year Miscalculation
Another problem with the year 2000 that is not a DRD problem occurs
because many programs won't recognise that the year 2000 is a leap year.
As the U.K. Health and Safety Executive says: Please pay no attention
to anyone who tells you otherwise. There is a February 29th, 2000.
Some programs have implemented mistaken rules for leap years.
A year is a leap year when
(see, for example, Claus Tondering: Frequently asked questions about Calendars.)
- the year is divisible by 4,
- the year is not divisible by 100,
- but when the year is divisible by 400, it's a leap year
This method of calculating leap years is standardised in the European Standard EN 28601 (which is German standard DIN 5008).
Programs that implement shortsighted bugfixes (for example, shifting the `time window', say by subtracting 30 from every date), without paying attention to the boundaries of the window, will sooner or later have the same problem over again.
Briefly, specific problems with the year 2000 are:
Back to Contents
Standard Date Representations
The last point in the problem list,
the lack of a standard for date representations,
is not necessarily a Year 2000 problem. However, adherence to
a standard would (have) solve(d) most of the Year 2000 problems.
There is such a standard. The International Standard ISO 8601 requires the representation "YYYY-MM-DD". This is prescribed by European Norm EN 28601 and German Industry Norm DIN 5008. This standard has two DRDs: At year 0 AD and at year 10,000AD. The standard does not prescribe what internal representation this shall have ( signed integer, unsigned integer, etc., but the date format itself is explicitly unsigned - AD is assumed). The DRD at 0 could be a problem for archaeologists or ancient-historians, whose databases may need to represent dates BC (that is, as a signed integer). We will leave it to the reader to determine if the DRD at 10,000AD is problematic.
Back to Contents
Finer Time Representations
There are more fine-grained representations of time than by days.
If one measures time in seconds, then it can be very hard to
determine in advance when DRD will occur. The reason is that
Universal Coordinated Time (UTC) adds leap seconds according
to need. Leap seconds are added by convention, and are dependent
upon physical processes (changes in the rotation of the earth, and
of the earth about the sun), that are imperfectly predictable
(indeed, imperfectly understood).
Thus it is not possible to determine today when leap
seconds will be needed in the future. For more information,
see the RISKS article
A definitive clarification of time measurement
in volume 19(14), 14 May 1997, by John Laverty and Peter Ladkin.
Many companies and computer users have realised the problem too late to perform proper checks - or haven't realised it at all yet! Any system which uses dates or a clock can be vulnerable. One of the problems is that the clock may be hidden. Here is a quick run through some issues.
Back to Contents
Consequences of Y2K, and DDP Avoidance
No one has determined how many resources will be used up dealing with the
Millennium Bug. Estimates are many billions of dollars worldwide.
Neither is anyone able to determine the extent of the problem. Estimates
from computer professionals have ranged from
Given the published experience of those who have diligently searched for Y2K
problems in their systems, we judge it more likely that the millennium
bug has been technically underestimated than that it has been overestimated
(cf. the quote from Thomas, above).
Avoiding Such Problems in the Future
Although one will simply have to deal with whatever the consequences of the
millennium bug will be, avoiding data discontinuity problems in computer
systems is straightforward.
Data types, including ranges, must be explicitly specified either in the
requirements or when designing a computer system; and it should be
determined that overflows would be explicitly announced and correctly
(Partial lack of such measures accounted recently for the Ariane Flight
501 failure: see
The Ariane 5 Accident: A
Programming Problem? by Peter Ladkin, Research Report RVS-J-98-02,
and An Analysis of the Ariane 5 Flight 501 Failure - A System
Engineering Perspective by Gérard Le Lann, IEEE Symposium
and Workshop in Engineering of Computer-Based systems, 1997.)
Such measures are a routine part of a normal rigorous specification process. Such a specification process is adequate if it is possible to prove, formally or informally, that the design of the system fulfils its requirements, and if the coding of the system fulfils its design specification, and if the hardware correctly executes the programs according to the semantics of the language in which the code is written.
Software engineers experienced in the use of formal methods have been advocating and using such procedures, especially for safety-critical and other mission-critical systems, for decades. Such methods have by and large been used in the design of security-critical systems, and are beginning to be applied more widely for safety-critical system development, although some domains (military avionics systems) are more advanced in this respect than others (hospital health care apparatus). The emergence of the millennium bug may serve to give momentum to this effort. It provides a significant argument for rigorous specification, requirements and design analysis either on economic grounds (more formal development would have saved most of the resources used later for post hoc analysis of Y2K vulnerabilities), or on grounds of the dire consequences of the millennium bug. It seems prudent at this point to hope for the former but plan for the latter.
Back to Contents
Information about Year 2000 Problems
has written some short but splendid articles
attempting to categorise the extent of Year 2000 problems. We
include them below by permission and with gratitude.
Peter de Jaeger has collected and linked a vast amount of information concerning Y2K, and wrote already in September 1993 that time was running out to `solve' the Year 2000 problem (for example, in a quote from his article Doomsday 2000).