The following Y2K material has been kept available by MITRE for historical purposes only and has not been updated unless noted.
|Dealing with Dates:
Solutions for the Year 2000
The Year 2000 (Y2K) problem is the software problem of the 20th century. This article defines the concepts, terminology, and individual aspects of the Y2K effort and presents a process an organization can use to address its own Y2K challenge in a forthright and level-headed manner. Solutions, compliance definition, testing, and costs are also addressed in this article.
Freud completed his Interpretation of Dreams in late 1899 and copies were already circulating, he postdated the title page to the first of the year
because he wanted to establish psychoanalysis as a
20th-century science. Computer scientists working today on the
"Misinterpretation of Dates," more commonly known as the Y2K problem, probably wish they could postpone the
unveiling of their work as easily and avoid the establishment of system disaster recovery as a
The Y2K problem is real, though we still do not have a true sense of how extensive it is. Studies to define the scope of the problem and the costs to fix it have produced widely varying results, which causes confusion and concern. The Y2K problem has caught the media's attention and the public's imagination, and it has stimulated aggressive vendor response. Approaches to resolve the problem and manage the risks tend to focus on how particular tools and vendors can help. In this article, I first will discuss the concepts, terminology, and individual aspects of a Y2K effort, then I will define a process an organization can use to address its own Y2K challenge in a forthright and level-headed manner.
Y2K Problem Defined
For whatever reasonto save precious memory in an era when memory was incredibly expensive, because systems were not expected to last this long, or simply because the problem was not recognizedprogrammers 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 Dec. 31, 1969 until IBM 360s all over Europe began to fail at midnight, local time. As the failures progressed from time zone to time zone around the globe, 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 created a longer-term patch for the problem.
Briefly defined, the Y2K problem involves any or all of the following:
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 personal computers were initially built to augment mainframe systems and use their data.
The Y2K problem is exceptionally 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, electronic data interchange and banking systems, spreadsheets, PBXs (private branch exchanges), telephone systems, and more. The Y2K problem is not merely an information systems (IS) problem. Although the majority of Y2K problems are located in ISs, the sad truth is that systems anywhere that use dates may be threatened.
It is naive to assume that new applications and systems are immune to the Y2K problem. 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 personal computers containing three 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, it has a deadline that will not move and is common to everyone. And we will all be competing for scarce resourcesCOBOL programmers and testing personnel, for example. Second, it affects every system that has an external interface. Therefore, fixes for interrelated systems must be fielded simultaneously; otherwise, systems could be inundated by the proposed changes from systems with which they interface. Third, instead of the traditional reaction to a maintenance problem"Here's the problem, fix it"the reaction to a Y2K problem is "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 how a fix is fielded. For example, the new U.S. acquisition regulation interim rule mandates the use of Y2K warranty language that defines 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." 
How Much Will It Cost to Fix?
It is difficult to estimate the cost of the Y2K problem. The Gartner Group estimated that costs for the U.S. Department of Defense (DoD) alone could start at upward of $30 billion, and worldwide costs could approach $600 billion. A more detailed analysis of specific DoD systems in 1995 by MITRE looked at 5.4 million lines of DoD code from nine command and control and two information systems . The study found that only 1.16 percentor about 62,600 lines of codeinvolved date manipulation, and this code was contained in 10.03 percent of the modules in the systems. The MITRE study estimated that corrective maintenance to these systems would cost between 75 cents and $1.70 per line for application information systems and from $1 to $8.52 per line for command and control systems. Other experience reports suggest that between 10 percent and 15 percent of IT systems code is typically affected .
These dollar rates can be used to calculate a rough order of magnitude (ROM), or first-cut estimate of an organization's potential Y2K costs. ROM estimates use a cost multiplier to translate software size (in executable lines of code) into a dollar estimate. The ROM-estimate approach is based on the assumption that there is a general correlation between the application type and the density and distribution of dates in source code. These metrics can be used in conjunction with maintenance productivity rates to model the cost and effort to fix these types of applications. These models are then used to derive the cost multipliers.
ROM-based estimates do not reflect the costs to upgrade commercial-off-the-shelf (COTS) products, work around inaccessible documentation for software or firmware, or produce and field new chips. You must quickly move beyond ROM estimates to detailed cost estimates based on the actual problems and the planned solutions. Use an appropriate set of work breakdown structure costs to make visible the necessary allocation of resources to critical areas. Answer "what-if" questions concerning budget vs. technical trade-offs, justify future Y2K funding, and understand the business consequences of your decisions.
When preparing Y2K solutions, every organization must be mindful of all relevant auditing criteria, accounting standards, and financial disclosure requirements. More detailed cost estimates not only support formal audits and disclosure but also provide input to the business plans and corporate strategies affected by the impact the Y2K problem can have on cash flow and tax liabilities.
The leap year, magic number, and date counter overflow problems can be repaired with straightforward corrections wherever they are found.
The same is not true for the incorrect handling of the two-digit year. 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 will be a major part of any solution approach. Bridges convert between old and new data formats and programs or between external and internal formats. Some bridging will allow updated components to be deployed separately, while others will become long-term structural pieces of the systems.
To take 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 that can be combined as appropriate to deal with an organization's Y2K problems:
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 that accesses the internal structures will corrupt the revised system.
This solution is complete, and it ensures the applications will operate correctly for the next 2,600 years. However, it involves the modification of every program and every database that references date data; the adjustment of every positional reference to data fields; changes to the format of every record that contains date data; and a reformat and rewrite of every data file, including historic data files.
This approach may also require a change to the format of messages among systems. The changes will initiate a chain of modifications that will require simultaneous testing and rollout of the new systems across organizations.
Encoding Century Information in a Six-Digit Space
Century information can be encoded into the same space currently occupied by the standard six-digit date field (YYMMDD). This might be done to address disk performance tuning and balancing issues or because of rigidly defined field sizes in standard messages. There are at least five ways to do this:
Figure 1. The 100-year sliding window .
The logic-window technique does require some extra overhead and code logicdates, sorts, collations, literal
comparisons, and computations must be correctly mapped to the two-digit date to assure that computations are correctly
performed. However, this technique avoids most of the massive changes and interorganizational coordination associated
with the expansion approach. As long as old data is dropped and the 100-year span of dates is retained, applications that use
a 100-year sliding window will continue to unambiguously interpret date data and calculations for a long time.
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 the uses of dates be modeled more precisely to distinguish between fields that should be expanded and those that should not.
If an application deals with data that is more than 100 years apart, this approach cannot be used. However, many systems do not have to deal with time spans of more than 100 years. For them, this solution is extremely attractive because it requires no data changesonly programs are changed.
Data Bridge Using a Logic Window
This solution is popular because it allows for a fairly straightforward conversion of the applications to a four-digit year, yet allows external interfaces to continue in two-digit formats. This is done with simple data bridges that map the internal and external date data through a logic-window approach for all inputs and outputs.
Reverse the System Clock and Use a 28-Year Time Bridge
For systems whose source code is no longer available, cannot be replaced, or whose purchased components are not century ready, there is an option other than replacement: the system clock can be reversed by 28 years and bridging scripts can be written to 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. When 28 years are added to Saturday, Jan. 1, 1972, it will generate Saturday, Jan. 1, 2000. Note that this works only for periods that have a leap year every four years (1901-2100), which means this approach is good only until Feb. 28, 2100.
Replace or Retire 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 the purchase of a commercial product is to merge with or buy a company that has Y2K-safe systems and retire yours.
In some cases, the best option may be to do nothing. This is not the same as to ignore the problem. Rather, it involves an analysis of the risks 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, this kind of system would probably be fixed, but in the real world it is advisable to reserve resources for systems that will have more severe reactions to the date change.
Y2K Test and Evaluation
It is important to specify in some detail the goals and role of the Y2K test and evaluation effort. In many cases, it may be next to impossible to prove that the Y2K problem has been fixed. One reason is that many systems interface with components that cannot be rolled forward to test. Satellite networks and telephone systems are two examples. These interfaces can be simulated and analyzed, but it may not be possible to test them to the same level of confidence as other systems. The need to work with users should not be overlooked. They need help to understand the levels and types of risk the system has so they will remain confident in the system's performance.
Systems that undergo Y2K maintenance should be evaluated to determine their degree of Y2K compliance and whether this compliance is sufficient for organizational goals. Any testing activity should be aimed at gathering information to determine the degree of Y2K compliance.
Stage the testing and evaluation of purchased components early so that infrastructure errors do not mask the failure of the original application. Address the validity of licenses and passwords for the duration of the full testing period. Likewise, ensure that the testing environment and testing tools operate through the entire testing period. They, too, are susceptible to the Y2K problem.
Y2K testing requires a layered approach. Test applications in isolation, then test systems, then test a system of systems to the extent possible. These increasingly complex entities will have the same compliance requirements, but the approach to gathering data will be different for each.
Details for an overall Y2K assessment approach being used within much of the DoD can be found in the "Exit Criteria Checklist" (found at http://www.mitre.org/research/cots/COMPLIANCE_CHECKLIST.html) System time windows and the existence of various date-related rollovers of date counters complicate proper date handling. Each system functions in its own time window, which surrounds the present date. Planning and scheduling systems work with dates that are weeks, months, and sometimes years in the future. Trend analysis systems and billing systems regularly reference dates in the past. You will need to verify the ability of your system and its window of time to successfully process dates before and after the transition to 2000.
A Silver Bullet?
To successfully manage your Y2K effort, you may apply a wide variety of tool technologies. Many Y2K discussions focus solely on tools that can find and possibly fix the problems. But a larger set of toolsincluding testing, configuration management, project planning, and cost estimating toolsare just as important and possibly indispensable.
One caveat to the pursuit of tool technologies for Y2K is to do it appropriately rather than overwhelm and distract your staff from their jobs. It is extremely important that the introduction of new tools be compatible with your organization and that it not cause a paradigm shift that will lower productivity and reduce the quality of the work.
Tools to Locate and Fix Code
First, you need to find the code. Keep in mind that your inventory often includes systems that are homegrown, no longer maintained, or undocumented software, undocumented firmware, and COTS systems. You will need tools and techniques to find these components. Once found, scanning, tagging, and conversion tools can be used to place both the source code and documents on line.
Second, you can use analysis tools to search for possibly erroneous code, such as operating system search tools and commercial Y2K-aware search tools for application code. One of the most significant problems with using analysis tools to find the date problems in firmware and software is the false negatives and the false positives. False negatives are date problems that the analysis tools miss. False positives result when the tools spew out a plethora of potential problem areas that the analyst must then wade through to find the real problems. Both types of problems can be addressed with tools that more fully understand the context and usage of the dates, such as some of the reverse-engineering technologies that the Air Force's Rome Laboratory has helped develop and introduce into the commercial marketplace. These intelligent tools reduce the search to actual problemsfind date data by mining data dictionaries, message sets, file exchanges, variables, and so forth. These rule-based artificial intelligence tools can follow assignments and look for behaviors within the code, but they need specialized parsers, a great deal of computing power and memory, and some must first be programmed with your business rules to understand what to look for.
Although these intelligent tools are getting better, they are not silver bullets, and they will not solve the problem in its entirety. To make automation viable, you need to partner it with knowledgeable and skilled analysts. Given good parser technology, tools can detect most date-related lines, but there are still ambiguities that require humans to decipher:
Tools for Testing
Estimates suggest that testing will account for about 45 percent of the Y2K effort. One way to minimize the test effort is to use testing tools to develop automated and repeatable test methods. Test scripts and scenarios provide a reasonable, repeatable way to conduct effective stress tests of various problem dates.
Y2K testing is unique in that it requires testing at numerous points in time, and each test requires supporting test data and test scenarios. Table 1 shows sample dates to consider testingthe specific dates you need to test will depend on the composition of your systems.
1998-01-01 Flag Year 98
1999-01-01 Flag Year 99
1999-09-09 Magic Number 9/9/99
2000-01-01 Overflow 2-Digit Years
2000-1-10 First 9-Character Date
2000-10-10 First 10-Character Date
2000-02-29 Leap Year
2000-12-31 Day 366 of the Year
2001-01-01 21st Century
2100-01-01 Not a Leap Year
3000-01-01 Not a Leap Year
|Table 1. Some possible date-related failure dates.|
It is vital that systems developers be responsible for the correction and fielding of a fixed system. Organizations that set up central testing and clearing facilities encounter tremendous logistical and coordination problems in dealing with multiple environments and languages. The systems developers, who already possess development and test capabilities, are in the most cost-effective position to validate and verify the correct behavior of their own systems. What the central organization should do is provide adequate and specific criteria to assure that everyone is consistently finding and fixing the potential problems (see "Exit Criteria Checklist" in the "For More Information" section).
Tools for Project Management
Configuration management tools are indispensable to handle the rapidly changing system components and the performance of multiple regression tests. Given the varied steps and numerous parties involved, along with the stress of an immovable deadline, a good project planning and project monitoring tool set will be extremely valuable. Likewise, as the project moves forward from its initial rough cost estimate, cost estimating tools and models will be tremendously important in answering trade-off questions and keeping a handle on the actual impact of the Y2K remediation effort.
Because of risks, schedule constraints, and budget limitations, senior management must be pro-active in the oversight of Y2K efforts. Senior managers must have current information that allows them to make timely decisions about resources and priorities. To this end, MITRE has developed a "triage scorecard" designed to help managers
Figure 2. Y2K triage scorecard. R = red; Y = yellow; G = green; B = blue.
The Y2K triage scorecard, in conjunction with lower-level,
detailed status information, is a management tool that provides periodic reports
on the Y2K risks that may affect an organization's ability to do its job. A
full discussion of the scorecard and a spreadsheet version of it can be found
on the MITRE Y2K Web site (http://www.mitre.org/tech/y2k/docs/index.html).
Each row represents the status of a system, a subsystem, or a collection of interrelated or interoperating systems. Red (R) represents the highest risk and hence the highest priority in making changesit requires immediate attention. Yellow (Y) represents moderate riskit should be monitored. Green (G) indicates that renovation is proceeding smoothly with low riskno management action is anticipated. Blue (B) indicates satisfactory solution of problems or completion of an activity. A blank field in the implementation status area means no activity has begun.
The inventory step is distinct but usually considered the initial part of the assessing and planning phase. The percentages along the right represent ranges for the activities according to industry surveys.
Where to Start - A Y2K Process
A typical Y2K effort has five major phases, as developed and used by the DoD . The process can be tracked with a scorecard or some similar mechanism (Figure 2). Upper management should be apprised of the process at each phase. Figure 3 illustrates the five phases:
Figure 3. The relative amount of effort will differ for each phase of a Y2K project.
Each organization must educate its employees about what the Y2K problem is and how to deal with it. Many have a hard time believing that something as trivial as a lack of two digits in a date can cause a serious problem.
Inventory, Assessment, and Planning
This phase involves eight steps:
Here, you test fixes with an exit criteria checklist. To test fixes to Y2K problems will require new and expanded procedures compared to our traditional approaches. On top of all this, as mentioned above, systems typically deal with a window of timea range of dates both before and after the present datethat requires testing beyond Jan. 1, 2000.
In this phase you proceed to field (or in most cases, re-field) the fixed systems. This includes the training necessary for the system's users. Although most organizations will be able to use their traditional methods to field new systems and upgrades for the changes needed for Y2K, there will probably be several additional issues that impact their traditional approach. The need to ensure that all changes are implemented on time against a firm, no-slip deadline will be new for many organizations. The simultaneous change of commercial components, developed components, and procedures also will be new for many. Finally, for those forced into a change in their interfaces, the coordination and simultaneous activation of your new release with your interfacing partners will be especially challenging when more than one interface is changing.
The Y2K problem will cause some bizarre and possibly unexplainable happenings. Peter de Jager tells of a Scottish bank that was so confident of its systems that it overruled its Y2K service provider's desire to continue testing. The bank advanced the year and began to run reports. One looked rather peculiar. After long study, one of the bank's elder statesmen recognized it as a printout in the old fractional pounds, shillings, and pence. Apparently, when Scotland adopted a decimal system in 1971, the bank had used a date switch that caused every report generated after 1970 to use the new decimal format instead of the old fractional units. But when the time was advanced to 2000, the part of the system that used the date switch thought it was back in 1900, so it reverted to running the old reports.
I hope this article helps you to avoid a similar mishap. Y2K is solvable, but it will take a reasoned and thorough effort.
The summary work contained in this article was funded by the MITRE Corporation and is based on the composite effort of all the individuals at MITRE that work on the Y2K effort. Special thanks to Thomas Backman, Michael Brenner, Judith Clapp, Paul Garvey, Calvin Groenewould, Lawrence Shafer, John R. Roberts, John Vitkevich, and Barbara Wolfinger for their thoughts, ideas, and efforts in dealing with the Y2K efforts on which this article rests.
About the Author
Robert A. Martin is a manager
within MITRE Bedford's software engineering products and practices section, where MITRE
promotes the use and development of various product and process assessment technologies and methods.
MITRE became involved in researching, addressing, and facilitating their customers' Y2K efforts in 1995. One part of their effort is a Y2K Web site that
addresses Y2K issues from a DoD perspective. Martin and his group work with the majority of MITRE's DoD customers (as well as MITRE)
to address the Y2K problem. Martin received a bachelor's degree and a master's degree in electrical engineering from Rensselaer
Polytechnic Institute and a master's of business degree from Babson College. He is a member of the IEEE and the IEEE Computer Society.
202 Burlington Road
Bedford, MA 01730-1430
For More Information
MITRE has established a clearinghouse for Y2K information on a Web site that includes papers and presentations, templates and work sheets, discussion forums, cost estimation help, and links to other Y2K sites.
The Web site also provides a catalog of Y2K tools, services, and consultants, although we do not endorse the companies and products listed in the catalog. The newest part of MITRE's clearinghouse provides information about the status of COTS hardware and software with respect to their ability to handle the transition to 2000, leap year, and other time-related sources of problems.
We welcome contributions of information and solutions from all quarters and have provided simple submission forms for this purpose.
MITRE also has ongoing research investigations into enhancing commercial reverse engineering-based Y2K analysis tools. We also are exploring the potential payoff in reworking compilers to overload date-related operators so that they correctly handle transcentury two-digit dates. We are producing a proof-of-concept GNU-based compiler and exploring the viability of this approach with compiler vendors with an emphasis on compilers for DoD legacy systems. We also are exploring ways to use pattern matching and visualization to attack the problem of false positives discussed in the article.
This article is based on an article that first appeared as a cover feature in the March 1997 IEEE computer magazine, COMPUTER.
© 1997 IEEE. Reprinted with permission, from COMPUTER; Vol. 30, No. 3, pp. 44-51, March 1997.
For further information directly related to Year 2000 issues, please contact Year2000@mitre.org
Information is provided by the MITRE Y2K Team
Last modified: Thursday, 14-Feb-2008 09:21:03 EST