Year 2000 technical summary

Year 2000 technical summary

<< >>

This document is a work-in-progress at this time (1999-11-18).

1.0

Contents

	1.0 Contents
	1.1 Scope
	1.2 Dates and the PC
	1.3 Dates and Macintosh Computers
	1.4 Notes
	1.5 The problems
	1.6 Problem manifestation
	1.7 Date storage
	1.8 Date calculations

1.1

Scope

This documentation covers many of the technical details behind Year 2000 related software and hardware problems. It contains concise descriptions of software and hardware components which may be vulnerable to date problems, along with brief descriptions of how and why the problems occur, so that the solutions and implications may be better understood. Where relevent, pointers to 3rd party and vendor resources are given.
The systems discussed in general are the supported personal computers, systems and servers used within U.C.D. by Computing Services.
It is not a canonical list of every software package, bug or item of computer hardware, there are many other resource which address this (see References).

1.2	Dates and the PC

In general, there are 3 sources of date/time on a PC (excluding add-in cards either to designed to solve Y2K related problems or provide time from an external source for scientific purposes).

the RTC, real time clock
the BIOS
the OS

Most programs ask the OS, few the BIOS, and even fewer ask the RTC. The OS itself will set its own date and time from the BIOS at boot time. The BIOS gets the date and time from that stored in the CMOS RTC.
Most of the RTC chips in PCs are not Y2K compliant, they only store 2 digit years (some estimates put this figure at >80%). This is typically not a problem, as long as the machine BIOS and/or OS are aware of this feature. Many are, some are not, and some have faulty logic for deducing the year (for example AMI V4.5 BIOS code assumes that the year must be between 1994 and 1999, and will force it to be so).

1.3	Dates and Macintosh Computers

Incomplete at this time (1999-11-18).

1.4

Notes

Some notes:

Y2K is frequently used as an abbreviation of "Year 2000"
Where dates and times are specified in this document, they are typically formatted in accordance with ISO 8601 (or the equivalent EN 28601). On occasion example dates may be written so as to indicate the problem with ambiguous notation or specific Y2K weaknesses.
Jan 1st 2000, or any other date,is not the problem. Dealing incorrectly with the ramifications or computations of various dates are the problems

1.5	The problems

There are many large and small problems that can occur(¹), these result from program logic errors in the storage, calculation, input or output of dates. The side effects of a date error can be none, or significant.

Year representations

two digit years, and assume a "19" prefix: 1997, 1998, 1999, 1900
(this can be a problem with input or output of dates)
1900 offset: 1997, 1998, 1999, 19100 or 1900
(this is usually a problem with output of dates)

Magic dates

1999-09-09 (9th September 1999, i.e. "9999")
(sentinel values such as "9999" which mean something other than the literal data are common in programming, i.e. the end of a list, or the end of time)

Problematic dates

2000-02-29 (29th February 2000, 2000 is a leap year)
(leap year calculations are trivial, but not always implemented correctly)

(¹) this list is by no means exhaustive

1.6	Problem manifestation

Bad date sequence
missed or extra days(¹), months or years
Input Errors
two digit year input fields not accepting "00"
Output Errors
date output routines corrupting output after 1999
Date sorting failure
a sort operations based only on 2 digit years will fail to sort 2000 after 1999, since "00" comes before "99". (also for databases with an index based on a date field)
Bad day of week
optimised day-of-week algorithms which assume 1900, and use only the final digits of the year(²).
Other/undetermined behaviour
anything goes

(¹) 2000 is a leap year, for example (²) the first day of 1900 was a Monday, the first day of 2000 will be a Saturday

1.7	Date storage

Dates are stored in computers in a variety of internal formats, using a variety of schemes:

unpacked binary: the components of the date (year, month, day) are stored one per memory location, this is typically wasteful of storage
packed binary: the components of the date are stored as groups of bits packed in a single memory location, this is more efficient than unpacked binary (for example, MS-DOS stores the date in this format)
BCD: BCD is a packed binary method, but each decimal digit gets assigned a group of bits, which makes input/ouput easy, but the storage is not as efficient as packed binary (for example, the RTC stores the date in this format)
epoch based: the date is stored as an offset from a particular date, the Julian calendar uses the year 1 A.D. as its epoch (for example, UNIX systems often use January 1st 1970 as an epoch)

The actual time units used can be milli-seconds, seconds or days.

A common cause (but certainly not the only cause) of Y2K related problems is that in an attempt to save storage the century digit of the year were not stored and assumed to be "19". This restricts valid dates to the window [1900-1999]. Other systems (like some PC BIOSes) are smart enough to use 1980-2079 as the window, and assume years [80-00] to be in the 20th century, and years [01-79] to be in the 21s century.

1.8	Date calculations

The calculation of dates, past and future, and the amount of time between 2 dates is relatively complicated (leap year, leap seconds, time zones, daylight savings etc...). And given the origins of the calendar system which is based on seasons, the phase of the moon, and the whims of popes and emperors over the millenia, it's surprising that it works at all.

The only real way to handle date calculations is to convert a human readable date to a normalized date form (such as seconds since a particular epoch in a particular time zone), perform the calculations, and convert back to human readable form

human readable date -> computer input -> convert -> normalized form
normalized form -> convert -> computer output -> human readable date

Each stage input, output or conversion stage can introduce errors, typically related to the way human readable dates have significance or ambiguous shorthand.