The Year 2000 Faulty Date Logic Problem
The Year 2000 faulty date logic problem (or the "Year 2000 Problem,"
or the "Y2K Problem" as
it is commonly called) is defined as follows:
Insufficient definition of the data field
in programs and data bases that holds the year
datum. Back in the days when memory
and mass storage were expensive, programmers routinely
coded the year as a two-digit field (or
variable) in software applications and their
associated data bases to save memory and
storage space. Similarly, hardware that kept time
inside the computer (e.g. the clock inside
PC) either kept the year as a two-digit variable or
returned a two digit variable to the operating
system when time was checked.
The incorrect calculation of the
leap year. Even centuries are leap years only when they
are divisible by 400. So the year
2000 is a leap year, while 1800, 1900, and 2100 are not.
Many software programs have been found
that do not include February 29th, 2000 as a legal
date, or increment from February 28th
to March 1st, 2000.
The inappropriate encoding of "19" or
some other year as a base year, or "99" as the final
year. For example, the system used
by the British courts to schedule trial dates uses "99" as
an indefinite suspense code. If
nothing is done, the system will try to schedule all of these
trial dates in calendar year 1999.
The inaccurate programming of date calculations
with respect to these inaccuracies,
including computations, comparisons, assignments,
and other operations.
Because virtually every major application deals with dates, and
because of the widespread
(until only recently) encoding of the year as a two-digit field,
the likelihood that a
software application is affected by the Y2K problem is extremely
high.
Finding the problems: Identification of all the date data and date
calculations and their
impact on a computer system is complex. It is much more than
just setting the clock on your
system to January 1st, 2000 and seeing if the system crashes (WARNING:
if you do roll the
clock ahead as part of a testing program, you must be careful to
work with the software
application vendors - you may not be able to "roll the clock backwards"
because of changes
made by the application to data files in "future time." Additionally,
applications with
licenses that expire "in the future" may cease to function entirely.)
Standard software practices such as using pointers, look-up tables,
and arrays, muddled by
individual programming styles and naming conventions and masked
by dates embedded in other
data fields, all complicate identifying and correcting Y2K problems,
even if you have well
documented source code (rare). In any event, any system
that is not built from the ground up
to be "Y2K compliant" will require extensive testing to determine
that either there are no
problems, or that implemented fixes have in fact eliminated the
problems without introducing
new ones.
Possible impacts of the problem: Software in affected applications
may incorrectly assume
that the maximum legal value of the year field is "99," or may
incorrectly perform sorts or
other operations that involve years designated by "00," "01," etc.
Negative time duration
could result from subtractions from "00" instead of "2000."
For example, several supply stock
monitoring programs in commercial industry have already started
flagging items produced in
1997 with a 4 year shelf life as "Expired."
Harmful consequences range from outright application failure (computer
lock-up or system
crash) to incorrect results or aberrant program behaviors (generation
of faulty schedules,
generation of incorrect transactions, calculation of incorrect
weapon presets or ballistics
etc.)
QUESTIONS TO ASK:
1) What applications are we running? Are they "Y2K compliant?"
How do we know? Are they
listed in the DIST? If not, why not? What is
our plan to get required applications in the
DIST?
2) Is our hardware Y2K compliant? (e.g. most 286s and early
386s are not. Neither are many
older main frame and UNIX-based hardware and software operating
systems)
3) For our applications that are not Y2K compliant, is our plan
to fix, replace, or terminate?
What is the business and/or warfighting case for that decision?
4) Who does the life-cycle maintenance of our applications?
What is their Y2K plan? What are
the milestones? When will they be done? What are our
metrics that show they are on track?
How much will it cost? Who is paying? What confidence
do we have in the estimated costs? In
the schedule?
5) Even if there is enough time and money, do we have the right
people resources available to
execute our plan?
6) How are we managing the risks associated with either not fixing
all the problems or not
having enough time, money or people to fix the problems?
for a weekly
news letter on the y2k problem please click below