[Navigation] [Image]ITL Bulletins Online ITL Bulletin December 1998 [Image]USERS ON ADVISING INFORMATION TECHNOLOGY WHAT IS YEAR 2000 COMPLIANCE? At midnight on December 31, 1999, computers will roll the date over to January 1, 2000, and start what could be a treacherous time for automated systems throughout the world. Many computers that store the date using a 2-digit year format will interpret 01/01/00 as January 1, 1900, rather than January 1, 2000. Products are being converted to remove this threat, but users are asking what the rules are for determining if the changes have been performed correctly. There are numerous proposed and de facto definitions of "year 2000 compliance" (also called "Y2K compliance"), but each is different in one or more respects. Even though definitions attempt to describe some sort of order in the disorderliness of the marketplace, these differences in definition stem from individual perspectives and visualizations of the problem. In some cases, the differences come from simple misunderstanding of, or misconceptions about, the technical terminology. In all cases, the definitions denote complexities that may or may not affect everyone. As a result, many organizations and users are questioning the effectiveness of the definitions and posing specific questions concerning year 2000 compliance. Examples of these questions are: * What is the difference between a product that is year 2000 compliant and one that is year 2000 ready? * If a platform cannot handle dates after 2038, is it year 2000 compliant? * Is a product year 2000 compliant if it allows the use of 2-digit years? * Can a product be year 2000 compliant sometimes and not at other times? * What is year 2000 certification? These questions are really about separable issues: 1) those concerning year 2000 compliance, and 2) those concerning other issues about date processing, such as date calculations, date sorting, and comparisons of dates. This bulletin attempts to answer questions in both areas. Background The proliferation of year 2000 compliance definitions does not clear up misconceptions and ambiguities for those users grappling with the testing of products and applications to make sure that the century rollover from December 31, 1999, to January 1, 2000, is processed correctly. Many of the definitions reviewed for this bulletin contain very clear wording, but are couched in such broad terms that each user can come away with a different interpretation and consequently a different understanding. Conversely, some definitions are so strictly worded that it is impossible to imagine any way of satisfying the criteria. Examples of these definitions follow to provide a context for this bulletin. Important phrases are in bold text: * Institute of Electrical and Electronics Engineers "Year 2000 compliant technology shall correctly process date data within and between the 20th and 21st centuries, provided that: 1. the technology is used in accordance with its associated documentation, and 2. all other technology used with it properly exchanges date data with it." [IEEE2000.1] * British Standards Institute "Year 2000 conformity shall mean that neither performance nor functionality is affected by dates prior to, during, and after the year 2000. In particular: Rule 1. No value for current date will cause any interruption in operation. Rule 2. Date-based functionality must behave consistently for dates prior to, during, and after year 2000. Rule 3. In all interfaces and data storage, the century in any date must be specified either explicitly or by unambiguous algorithms or inferencing rules. Rule 4. Year 2000 must be recognized as a leap year." [BSI2000] * Hewlett Packard "A 'Compliant' product accurately processes date data (including, but not limited to: calculating, comparing and sequencing dates), from, into and between the twentieth and twenty-first centuries, the years 1999 and 2000, and leap year calculations, when used in accordance with its product documentation, and provided all other products used in combination with the product properly exchange data with it. HP also refers to this state as 'Ready.' Products which do no date related processing ("NDRP") are considered to be Compliant. For the few products that are Compliant and require specific customer action, such actions will be clearly detailed." [HP2000] * Bethlehem Steel Corporation "To be compliant a system/process must: 1. Handle date information before, during and after midnight, December 31, 1999, including but not limited to accepting date input; providing date output; and performing calculations and comparisons on dates or portions of dates. Date interpretation and manipulation must be correct for all valid date values within the application domain. 2. Function accurately and without interruption before, during, and after January 1, 2000, without any change in operations associated with the advent of the new century. 3. Respond to two-digit date input in a way that resolves the ambiguity as to the century in a disclosed, defined, and predetermined manner. Interfacing software must make the same century assumptions when processing two-digit years. 4. Process 2000 as a leap year. 5. Correctly handle any date fields containing non-date information and correctly handle a date held in a non-date field. 6. Correctly process any date with a year specified as '99' and '00,' regardless of other subjective meanings attached to these values." [BETH2000] * Government of British Columbia "To be 'Year 2000 Compliant' the system must correctly process date/time values beyond the year 2000 with no practical limitation on the range of dates supported. Specifically, the following criteria must be met: 1. Correctly processes all valid date/time values of the form 'YYYYMMDD' (B.C. government date standard). 2. All stored date/time values will provide an explicit indication of the century (e.g., '1996' provides an indication of the century, whereas '96' does not). This includes dates stored in databases, data files, data structures, internal dates, and hardware. All date/time values read and written will provide an explicit indication of the century in each instance. A 4-digit year is to be used in all interfaces, including user interfaces (data entry screens, reports, etc.). Processing to logically infer the century is not sufficient. However, it is acceptable to use a 2-digit year for data entry, providing that the century can be determined with 100 percent accuracy during the anticipated lifetime of the system. 3. External interfaces (e.g., to and from other systems) will prevent dates with no explicit indication of century from entering the system. 4. The year 2000 must be correctly treated as a leap year (e.g., February 29, 2000, is accepted as a valid date)." [BC2000] All of these definitions appear to be going in the same direction, but with a mix of requirements that are posing problems for users and vendors in determining if products are compliant. The next sections look at some of these requirements and how they relate to overall Y2K compliance. Common Requirements of Year 2000 Compliance There is a core set of requirements common to virtually all year 2000 compliance definitions. The requirements in this core are: * Date-based functionality must behave correctly and consistently for dates prior to, during, and after the year 2000. For example, date computations, comparisons, and sequences must produce the correct results during the transition from December 31, 1999, to January 1, 2000. * In all interfaces and data storage, the year in any date must be specified unambiguously as belonging in a specific century. This does not impose a 4-digit year format; only that a 4-digit year can be derived from the information provided. * The year 2000 must be recognized as a leap year. Other Requirements Other requirements tend to be generic, but are specialized to one or more perceived needs at the application level. They do not necessarily enhance the definition of Y2K compliance for everyone, and in some cases actually make it difficult, if not impossible, for a product to be compliant. Dates With 4-Digit Years Some definitions require an explicit 4-digit year format, going so far as to require 4-digit years in database storage or internal processing. This has more to do with the type of year 2000 conversion an organization has decided to use, rather than with the correctness or completeness of a year 2000 compliance definition. This requirement may lock out many products that use inferencing rules to determine in which century a year belongs. Types of Processing Functionality Date processing definitions often include, but are not limited to, calculating, comparing, and sequencing or sorting of date data elements. There is an unlimited number of functions that could be included, very few of which have anything to do directly with year 2000 compliance. An example of an issue in this genre is whether the dates are required to be human-readable. Regardless of these other processing requirements, the resulting date computations, comparisons, and sequences must be correct. Certification A requirement for certification of products is not uncommon in these definitions, but is not sufficient and is only vaguely understood by many users. Certification to many users implies that some sort of rigorous and repeatable test or audit procedure has been implemented and that the product or service certified has undergone this process and passed. Within NIST's Information Technology Laboratory (ITL), certification has a very narrow definition: 1) a consensus-based, publicly available standard must exist; 2) a published suite of test cases must be derived from the standard; 3) a test procedure must be defined; and 4) a qualified testing organization and facility must be employed to administer the tests and interpret the results. Certification then means that an independent testing authority certifies that an implementation has undergone the tests and that the results were correct. The testing authority does not certify that the implementation will run correctly in all circumstances and conditions, nor that the product will be suitable for all uses. Only users can make that determination. At the opposite extreme are certifications based on self-assessment by vendors or third parties contracted to perform certification services in the absence of a defined standard and rigorous test suite. The certification process may be extensive and based on general requirements, or it may be solely a promise by the vendor to provide fixes if any errors occur in the correct use of the product. Whether the vendor charges for this service is another question. General Constraints on Date and Time Processing Date spans are critical in date processing and have an effect on year 2000 compliance only if the 1999/2000 boundary is included. More commonly, the problem is in determining if an application uses spans of more than 99 years, whether or not the 1999/2000 boundary is crossed. Storing the information needed to be able to process time spans of 99 years or more is the limiting factor in many product implementations and is the major cause of the year 2000 computer problem. The amount of space required to store date information is dependent upon the architectural design of the particular platform (i.e., combination of software and hardware) on which the dates are stored and the level of detail required in the stored dates. For example, the date, December 31, 1999, can be stored in 8 digits as a string of characters, "19991231." Only 4 8-bit bytes (characters) are required to store a binary integer of this size (e.g., the largest number in a 32-digit binary number is 232-1=4,294,967,295). If one needs to store date and time information down to milliseconds from January 1, 0001, then 6 8-bit bytes are required to store an integer large enough to encompass such a time span. Some platforms can store dates down to milliseconds for a span of 500 billion years; others will run out of space in 2038 as a result of the design limitations placed on the hardware or software. (The 2038 limit is based on the largest integer number of seconds that can be stored in 231 binary digits to represent dates up through early 2038.) This means that some operating systems will not have a year 2000 problem, but may have a year 2038 problem before they run out of date storage capacity. The amount of space that is provided for storing date and time information is a function of the design parameters used initially in building the platform. The design parameters are based on a trade-off between cost and usable features provided in the finished product. Implementations of different software packages make use of the amount of storage space allowed to store date and time information in the design of the functions provided for manipulating date/time information. Some implementations provide date functions that can manipulate 4-digit years, while others provide functions that can manipulate 2-digit years. Still others provide both types of functions. This is necessary in many instances to provide compatibility between current versions of software and earlier versions that could provide only 2-digit date handling routines. With this background information, some of the answers to the year 2000 compliance questions identified at the beginning of the bulletin will become somewhat clearer. The following section provides answers based on the information in the preceding paragraphs. Answers to Year 2000 Compliance Questions 1. What is the difference between a product that is year 2000 compliant and one that is year 2000 ready? The legal community claims that in the absence of qualified, rigorous tests or standards that can be applied to all products in order to claim year 2000 compliance, anything can be compliant, even a product that has nothing to do with dates. If a product can be shown to process dates correctly across the boundary between December 31, 1999, and January 1, 2000; recognize that 2000 is a leap year; and perform other date processing functions including calculating, comparing, and sequencing date information for dates within the 20th and 21st centuries, then according to the core requirements, such a product is year 2000 compliant. Because there is no standard and no rigorous test to be applied across all products, however, legal experts are recommending the use of the phrase "year 2000 ready" to describe this product characteristic. "Compliance" connotes some level of rigor or traceability in the testing process. "Ready" carries no formal definition in this respect. They are, however, essentially the same when it comes to the year 2000. 2. If a platform cannot handle dates after 2038, is it year 2000 compliant? Some would answer yes to this question. Others would equivocate based on the assumption that, if a product cannot handle dates that are clearly in the 21st century, such as those past 2038, it cannot be compliant. If the product can handle the time spans required in a specific application, then year 2000 compliance may be a moot point. The span of dates required for a particular application is not a function of the year 2000 problem unless it crosses the 1999/2000 boundary. It is part of a different question in the sense that an application that does not manipulate dates before January 1, 2000, will not have the year 2000 problem. (It may have a year 3000 problem, but who will know?) It may have a 2038 problem since an implementation may not be able to store dates with years larger than that. (There are operating systems that will not have a year 2000 problem, nor will they have a 2038 problem.) 3. Is a product year 2000 compliant if it allows the use of 2-digit years? Whether a product provides the use of 2-digit or 4-digit years is also a question that is different from whether it is year 2000 compliant. The year 2000 compliance requirements are that a product be able to handle the rollover from December 31, 1999, to January 1, 2000, correctly, recognize that the year 2000 is a leap year, and produce correct date function results for the 20th and 21st centuries. Nothing in a minimum definition requires 2-digit or 4-digit year or year functions. Ostensibly, one or the other, or both may be included. If a product can determine unambiguously that a 2-digit year is in one century or another, and provide the correct results in date computations, comparisons, and sequencing, then the requirement appears to have been met. 4. Can a product be year 2000 compliant sometimes and not at other times? A product cannot be both compliant and noncompliant. It either meets the requirements of the definition or it does not. Another way of asking the question is this: Can a product be used in one situation and produce the right answers, and in another situation produce the wrong answers? A product that can process correctly formatted date information may have problems with negative and ill-formatted dates. For example, a negative date may be applicable to a specific type of situation (i.e., an offset number of years before a specific date), but the product may not be able to process negative dates. Another product may be able to process any kind of date. Both may still be year 2000 compliant. A different situation could exist in which four separate conditions could each result in a failure to process a date correctly. One may think of a platform as being comprised of four layers of software and hardware: 1) the lowest contains the digital hardware clock counter which measures increments of time and may or may not record the actual date, 2) the next contains the real-time clock and the basic input-output system which convert the increments of time into wall clock times and convert clock times into information that can be used by the operating system and applications, 3) the operating system which receives clock information and passes it on to applications through well-defined application program interfaces (APIs), and 4) applications that perform functions on date and time information received from the operating system. Inasmuch as many compliance definitions require that all of the technology be able to correctly exchange date information with the application, situations may arise in which the application can be shown to be compliant on one platform and not on another. In this case, the definition says the implementation is compliant in one situation and not in the other. This may lead to a vendor calling the product "year 2000 ready" because the product may be used on a platform that is not year 2000 compliant. If an application is purported to be year 2000 compliant, but it does not receive a properly formatted date from the operating system, the application is not necessarily noncompliant. In this case, the operating system may be the culprit or any of the other two levels below the operating system. The application may be compliant, but the upshot of the situation is that a user cannot perform the work needed. This example shows that year 2000 compliance can be context-dependent. 5. What is year 2000 certification? The description of certification at the beginning of the bulletin describes two extremes: 1) the independent testing authority model of certification, and 2) the self-assessment model. What users are looking for is something comparable to the independent testing authority model. There are several problems with looking in that direction. A consensus-based standard does not exist for describing date processing functionality. Since no standard exists (and it is essentially impossible to develop one because of the diversity of requirements in every application), a standard test suite cannot be derived. Without either of these, there is no means of defining absolutely what certification implies. A product-by-product certification test in which each product is tested according to its capabilities is not the same as certifying that a product meets the explicit testing requirements imposed by a standard. Even if a standard were developed for a particular type of implementation, certification would apply only to the product tested using a test suite based on the individual standard. A new test suite would be required for each standard involved. In the absence of a standard, each product must stand on its own. Vendors or third-party testing services may certify products as year 2000 compliant, but users must ask what process was used to make the determination that a product could be certified, and must ask to see the tests and results of tests used in the certifying process. Alternately, users must test the products themselves. Only then can users determine that a product meets the requirements of their particular applications and environment. Conclusion Year 2000 compliance means different things to different users. These differences occur because products are different, application requirements are different, computing environments are different, and users are different. The basic definition of year 2000 compliance has been boiled down to a common set of requirements as stated in the U.S. Government's Federal Acquisition Regulations (FAR): Year 2000 compliant, as used in this part, means, with respect to information technology, that the information technology accurately processes date/time data (including, but not limited to, calculating, comparing, and sequencing) from, into, and between the twentieth and twenty-first centuries, and the years 1999 and 2000, and leap year calculations, to the extent that other information technology, used in combination with the information technology being acquired, properly exchanges date/time data with it. [USGOV2000] This is the essence of the core requirements described at the beginning of this bulletin. The perceptions of users that a product is year 2000 compliant or not, is not debatable. From the user's perspective, it is Y2K compliant or it is not. If other requirements or environmental factors are added to the compliance requirements, then the question of compliance becomes much more complex. What to Do Learn as much as possible about the year 2000 problem and its solutions. Develop a definition of year 2000 compliance for use within the organization. Determine which products in use within the organization are compliant and which ones are not by inventorying all software, hardware, data, networks, and tools; contacting manufacturers to ask whether their products are Y2K compliant; and determining what to do about those products that are not compliant. Develop a plan to repair, replace, or retire noncompliant components. Work with those people who are designing and testing the conversion of systems to make sure they understand the meaning of year 2000 compliance. A product, without saying anything about the specifics of the implementation or design, either produces the correct results for the change from December 31, 1999, to January 1, 2000; recognizes 2000 as a leap year; and correctly performs date calculations, comparisons, and sequencing for dates in the 20th and 21st centuries; or it does not. Proving this is a time-consuming and expensive proposition. References [BC2000] "Year 2000 Compliance Definition for the Government of British Columbia," Government of British Columbia, http://www.y2k.gov.bc.ca/htmldocs/y2kcompl.htm, September 25, 1998. [BETH2000] "Year 2000 Compliance Definition," Bethlehem Steel Corporation, http://www.bethsteel.com/ns-search/2kdef.html?NS-search-set=/360b9/a aaa000Bv0b9e07&NS-doc-offset=3&, September 25, 1998. [BSI2000] "A Definition of Year 2000 Conformity Requirements," British Standards Institute, http://www.bsi.com.uk/bsi/disc/year2000/year2000.html, September 25, 1998. [HP2000] "HP Year 2000 Compliance Definition," Hewlett Packard, Inc., http://www.hp.com/year2000/compliance.html, September 25, 1998. [IEEE2000.1] "IEEE Standard for Year 2000 Terminology," IEEE STD 2000.1-1998, Institute of Electrical and Electronics Engineers, Piscataway, NJ, 1998, p. 3. [USGOV2000] "Federal Acquisition Regulation; Year 2000 Compliance, 48 CFR Part 39," Federal Register, August 22, 1997, Volume 62, Number 163, Rules and Regulations, U.S. Government Printing Office, p. 44830. To Top [Image]ITL Bulletins Online