What is the Y2K
Problem?
Overview of Problem
Studies to define the scope of the Y2K
problem and the costs to fix it have produced widely varying
results, causing confusion and concern. The problem has
caught the media's attention and the public's imagination,
and it has stimulated aggressive vendor response. Almost all
computer-based systems will be adversely affected by the
arrival of the Year 2000 (01/01/2000), unless action is
taken now to replace, update, or change components of these
systems to eliminate or otherwise mitigate the effects of
this event. Fixing
and testing the problem poses a significant problem for
system and particularly software maintenance.
For whatever reason—whether they wanted
to save precious memory in an era when memory was incredibly
expensive, or because they didn’t expect systems to last
this long, or because they simply didn’t recognize the
problem—programmers long ago adopted a two-digit
convention to represent the year. This convention will cause
failures as we approach the turn of the century and beyond.
The problem has precedent: Few realized that the IBM 360
could not handle dates past 31 December 1969 until 360s all
over Europe started failing at midnight local time. As the
failures progressed around the globe, following the
timezones, IBM identified the problem and was able to
provide its American and Asian customers with a temporary
fix by telling them to lie to their computers about the
date. Meanwhile, IBM proceeded to create a longer-term patch
for the problem.
Unfortunately, the problem is not isolated
to programming errors caused by the use of the two-digit
year coding scheme. The year 2000 presents a "triple
witching hour" of potential traps for designers and
coders. In addition to the two-digit year coding, there are
distinct issues surrounding the use of the six-digit date
representation, and still other risks caused by the
calculation of the leap year. And just to make matters
worse, January 1, 2000 falls on a Saturday. Problems caused
by coding errors may not be discovered until the next
regular working day, allowing enough time for the errors to
inflict a great deal of damage.
Y2K Problem Defined
Briefly defined, the Y2K problem involves
any or all of these:
Representing the year as a two-digit
number, causing failures in arithmetic, comparisons,
sorting, and input/output to databases or files when
manipulating date data: incorrect software will assume
that the maximum value of a year field is "99"
and will roll systems over to "00" which can be
mistakenly interpreted as 1900 rather than 2000, resulting
in negative date calculations and the creation of many
overnight centenarians.
Incorrect leap year calculations will
assume that the year 2000 has only 365 days instead of
366. What’s more, although January 1, 2000 is the
primary witching hour, many date-dependent algorithms and
forward-referencing systems are already beginning to fail
due to not properly classifying years divisible by 400;
and
Software values involving limited date
ranges, including hardcoded values and "magic
bullets"
Limits to system date data types in
hardware registers
These can be more fully described as follows.
Two-Digit Year/Six-Digit Date Coding
Use of two digits to represent the year is
expected to be the most common cause of year 2000 failure.
Applications that require the user to enter a date routinely
present a two-digit field to the operator in an attempt to
reduce the number of keystrokes needed to enter data.
Failure to append the correct century to the value after
input results in an inability to distinguish between 1900
and 2000. For the most part, this shortcoming was not an
issue earlier in the century; however, as the year 2000
approaches, the capability to differentiate between dates in
the twentieth century and dates in the twenty-first century
will be a necessary requirement for a successful system.
This is also referred as six-digit date coding, since two
digits are often used for each of the month and day fields
as well as the year field. Six-digit date coding is common
in administrative information systems. Planning and
scheduling systems, human resources systems, financial and
billing systems, and many other programs use the convention.
This coding method is typically used where the application
is attempting to determine which of two dates is earlier in
time, or if a certain deadline has passed. These tests are
frequently coded with a single inequality statement used to
compare the two six-digit dates.
Calculating Leap Years Correctly
The second complicating factor in the
millennium problem is the leap
year calculation. It is evident that many people are
unaware of the rules for determining whether the current
year is a leap year. In fact, one user wrote a Software
Problem Report against the run-time library routines for an
operating system complaining that the year 2000 was being
incorrectly identified by it as a leap year.
The year 2000 IS a leap year. The three
rules which the Gregorian calendar uses to determine leap
year are as follows:
1. Years divisible by four are leap years,
unless...
2. Years also divisible by 100 are not
leap years, except...
3. Years divisible by 400 are leap
years.
Therefore, the year 2000 is a leap year
according to rule number three.
For some additional information on leap
years and how they came about, please see the leap
year explanation.
Hardcoding and Magic
Numbers
The third area of
problems comes from hardcoded values in software routines
such as "19" for the implied century and/or use of
"99" and "00" as reserved values meaning
"never delete this" or "this is a
demonstration account," respectively (sometimes called
"magic numbers") which limit the range of year
values and may cause date comparisons to fail or pollute
output values. Other magic number dates include: 9/9/99,
99/99/99, 1/1/1, 1/1/11, 6/9/69, 6/7/89, 1/23/45, 6/6/66,
7/7/77, 8/8/88, and 12/31/99. For a list of these and other
dates to test around, please see our Comprehensive
List of Potential Y2K Problem Dates. Although for your
Year 2000 testing, you may want to focus on those involving
99 and 1 in the years' position.
Limiting Date Range Size
The fourth and final area of problems is
platform limitations. Specifically, the internal date
representations of COTS hardware and software components,
software date data types which are stored as an increment
over some base date, may roll over and fail due to the
storage register filling up. This is the problem facing many
Global
Positioning Satellite receivers when their internal week
counter rolls over its 10-bit counter on August 21, 1999.
Additionally, not all PC BIOSs are Year 2000 compliant.
Older PCs may require a BIOS
upgrade (a process often called "flashing the
BIOS" to existing hardware with the capability), or
must be patched
/ manually
set to operate properly for the Year 2000.
How Vast is the Problem?
Just as today’s railroad uses a rail
standard derived from the width of a Roman chariot, modern
computer systems inherit their default conventions from the
mainframe era, when it was common practice to encode the
year as a two-digit field. After all, workstations and PCs
were initially built to augment mainframe systems and use
their data. So this mainframe practice has spread throughout
our systems.
The Y2K problem is very widespread: It
affects hardware (BIOS,
real-time
clocks), embedded
firmware, languages and compilers, operating systems,
random number generators and security services,
database-management systems, transaction-processing systems,
EDI and banking systems, spreadsheets, PBXs, phone systems,
and more. Y2K is not simply an IS problem: Although the
majority of Y2K problems are located in information systems,
the sad truth is that any system anywhere that uses dates
may be threatened.
In addition, we've all been striving to
maximize the use of Commercial
Off-the-Shelf (COTS) platforms, operating systems, and
applications in all of our new or updated systems.
However, the effects of doing this may turn out to be
another source of disruption that needs to be managed when
it comes to the Year 2000 problem.
The interdependencies of organizations
using C4I systems through rapid data exchanges and
multiple interfaces will certainly lead to scheduling,
testing, and coordination problems.
It is naive to assume that new
applications and systems are immune to Y2K. It was only late
last year that a new version of Quicken, a popular personal
finance package, was released that could handle dates beyond
1999. At the January Federal Interagency Y2K meeting, it was
reported that the National Institutes of Health received a
shipment of brand-new PCs containing three different
versions of BIOS, two of which failed to correctly handle
the century transition.
What Makes It Unprecedented?
Although similar to other software
problems, such as the four-digit zip code extension, the Y2K
problem has some peculiarities that make it more than a
standard maintenance problem. First and foremost, it has a
deadline that not only won’t move but is common to
everyone. We will all be competing for scarce
resources—COBOL programmers and testing personnel, for
example. Second, it
affects every system that has an external interface,
because these systems could be inundated by the proposed
changes from systems with which they interface—fixes that
will have to be fielded simultaneously. Third, instead of
the traditional maintenance problem—"Here’s the
problem, fix it"—the Y2K problem becomes "Where
is the problem and what are the fixes?"
Testing,
validation, and fielding will consume the lion’s share
of the costs associated with fixing the Y2K problem. For
some, the solutions
may be influenced, complicated, or dictated by legislative
or regulatory mandates. Other regulations will simplify
fielding a fix. For example, the new US acquisition
regulation interim rule mandates the use of Y2K
warranty language, defining compliance as
"information technology that accurately processes
date/time data (including, but not limited to, calculating,
comparing and sequencing) from, into and between the [20th
and 21st] centuries, and the years 1999 and 2000 and the
leap year calculations."
Related Links:
The
Y2K Page
Dealing
with Dates: Solutions for the Year 2000
A
Framework for Estimating the Cost of Fixing the Year 2000
Problem
Y2K
Material Available for Downloading
TOP
