Clock Problems, Rollovers and PCs
The leap year, magic
number, and date counter overflow problems, like PC
BIOS, often have available corrections from supporting vendors and
should be used wherever they exist. You yourself can test
the operation of your desktop PC's internal clock and BIOS. You
can also use one of the prepackaged PC BIOS compliance checkers that
are intended to be user-friendly and somewhat self-explanatory. Once
a problem has been observed, there are patching
techniques and third party solutions that can be used on most older
PCs.
Date Formats in User Data
For dealing with the incorrect handling of two-digit years, a variety
of approaches are available and should be evaluated to identify the
one that best suits your organization's priorities, resources, and schedule.
Bridging mechanisms using compliant libraries will be a major part of
any solution approach. These convert between old and compliant data
formats used in programs or between external and internal formats. Some
bridging will allow you to deploy updated components separately, while
others will become long-term structural pieces of your systems. Conversions
using bridging and common libraries are available for many platforms
and languages. Some examples of compliant libraries are:
Source analysis tools involve searching for dates and determining the
impact analysis of potential fixes involving conversions. For the first
problem, date keywords are used, for which there is considerable experience
(see sample keyword lists). Impact analysis
involves following data flow for inputs, parameters and constants to
determine areas affected by potential non-compliant values. Many
tool vendors provide approaches to doing this.
Taking special care in the design and functionality of the bridging
pieces can prevent performance degradation. There are at least seven
major, viable courses of action, which can be combined as appropriate,
to deal with an organization's Y2K problems:
The Y2K problem is very sensitive
to the solution approach. The solutions will also heavily influence
the scope of the changes, testing, and the degree of interorganizational
coordination that is required. Careful review of alternative solutions
can reduce the magnitude and scope of the effort and hence the cost
and risk.
Expanding the Year Field to Four Digits
This solution requires all references to and uses of a two-digit year
format (YY) be converted to a four-digit year format (YYYY), and all
programs must be converted to use the new format. The major risk in
this approach is that a program may directly access the internal structures
of a date field, thus changing the field size without also changing
the logic accessing the internal structure will corrupt the revised
system.
This solution is complete, and it ensures that your applications will
operate correctly for the next 2,600 years. However, it involves modifying
every program and every database that references date data; adjusting
every positional reference to data fields; changing the format of every
record that contains date data; and reformatting and rewriting every data
file, including historic data files.
This approach may also require changing the format of messages among systems,
initiating a chain of changes that will require simultaneous testing and
rollout of the new systems across organizations.
Encoding
Century Information in Six Digits
There are at least five ways to do this:
- Encode full Julian Dates (the number of days elapsed since noon
January 1, 4713 B.C.4 ) in a binary 48-bit field, allowing values
for dates well beyond anything we should care to record (YYMMDD [left
arrow] BBBBBB, B = 8-bit binary).
- Use the two 8-bit YY fields to encode the full year in a binary
16-bit field, allowing values for the years of 216 -1=65,535 (YYMMDD
[left arrow] BBMMDD, B = 8-bit binary).
- Encode a century field (0 = 18, 1 = 19, 2 = 20, and so on) and replace
the MMDD with a day-of-the-year field DDD (YYMMDD [left arrow] CYYDDD).
- Encode a century field as above and encode the month as a character
field (M*) with values 1-9, A, B, C representing the 12 months (YYMMDD
[left arrow] CYYM*DD).
- Encode the entire six-digit date field into an offset from 1 January
1900, which would also be good for the next 2,600 years (YYMMDD [left
arrow] DDDDDD).
Using Logic
Windows
Using this approach, a system unambiguously determines the century or
decade of a given year by comparing the value in a two-digit year field
against an application window. One version of the window technique allows
the span of years an application processes to be indefinitely extended
by periodically changing the window boundaries and notifying users that
the window is about to advance. This sliding window can be periodically
advanced as needed.
The logic window technique does require some extra overhead and code
logic -- dates, sorts, collations, literal comparisons, and computations
must be correctly mapped to the two-digit date, to assure that computations
are correctly performed. However, it avoids most of the massive changes
and interorganizational coordination associated with the expansion approach.
As long as old data is dropped retaining the 100-year span of dates,
applications that use a 100-year sliding window will continue to unambiguously
interpret date data and calculations for a long time to come. See examples
of logic window solutions for FORTRAN,
C, and Ada.
Applications that have some large date spans may be corrected with
a combination of the expansion and sliding window approaches. Such a
mixed approach requires that you model the uses of dates more precisely,
to distinguish between fields that should be expanded and those that
should not.
If your applications deal with data that is more than 100 years apart,
you cannot use this approach. However, many systems don't have to deal
with time spans of more than 100 years. For them, this solution is very
attractive because it requires no data changes -- only programs are
changed.
Employing
a Data Bridge Using a Logic Window
This solution is very popular because it allows for a fairly straightforward
conversion of the applications to a four-digit year, but allows external
interfaces to continue in two-digit formats by having simple data bridges
that map the internal and external date data through a logic window
approach for all inputs and outputs.
Reversing
the System Clock and Using a 28-Year Time Bridge
For systems that no longer have the source code, cannot recompile the
source code, or have purchased components that are not century ready,
there is an option other than replacement: You can reverse the system
clock by 28 years and write bridging scripts that add or subtract 28
years from the date data. The number is 28 because this offset retains
the same days of the week and month. Adding 28 years to Saturday, 1
January 1972 will generate a new date of Saturday, 1 January 2000. Note
that this works only for periods that have a leap year every four years
(1901-2100). So this approach is only good until 28 February 2100.
Replacing
or Retiring the System
For some systems, the best option may be to replace them with Y2K-safe
commercial products that do most of what you need. An interesting alternative
to buying a commercial product is to merge with or buy a company that
has Y2K-safe systems and retire your own.
Doing Nothing
at All
In some cases, the best option may be to do nothing. This is not the
same as ignoring the problem. Rather, it involves analyzing the risks
in order to determine that the Y2K problem will either not cause a problem
or cause such minor problems that users can work around them and compensate.
For example, a system might sort something out of sequence for one reporting
period or produce only minor errors that have no impact on functionality.
In a world without resource constraints, you would probably fix this
kind of system, but in the real world it is advisable to go after systems
that will have more severe reactions to the date change.
Suggestions or Ideas
We would like to add more information about solutions. If you have current
activities, suggestions or ideas, please consider sharing them via the
solutions idea form. One such solution we would
like to share is Tim Hawkins' idea to use a mapping that would not require
changing the size of date data in existing databases. A
good discussion of such a technique that has been used as part of some
solutions is the one described by Tim who submitted this link using
our Y2K Solutions Idea form.
For More Information
For more information on estimating the problem and its ramification
on information systems, see the MITRE
Solution Briefings.
