IEEE Draft Standard for Year 2000 Terminology IEEE P2000.1/D3.4 Draft Standard for Year 2000 Terminology Prepared by the Year 2000 Terminology Study Group of the Portable Applications Standards Committee Copyright (c) 1997 by the Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street New York, NY 10017, USA All rights reserved. This is an unapproved draft of a proposed IEEE Standard, subject to change. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of IEEE standardization activities. If this document is to be submitted to ISO or IEC, notification shall be given to the IEEE Copyright Administrator. Permission is also granted for member bodies and technical committees of ISO and IEC to reproduce this document for purposes of developing a national position. Other entities seeking permission to reproduce portions of this document for these or other uses must contact the IEEE Standards Department for the appropriate license. Use of information contained in the unapproved draft is at your own risk. IEEE Standards Department Copyright and Permissions 445 Hoes Lane, P.O. Box 1331 Piscataway, NJ 08855-1331, USA Introduction (This introduction is not part of IEEE P2000.1, Draft Standard for Year 2000 Terminology) This introduction provides background on the rationale used to develop this standard. This information is meant to aid in the understanding and usage of this standard. This standard addresses the key industry concern over the existence of multiple terms and lexicons that carry varied meanings. IEEE has designed this standard to assist individuals and organizations in their efforts to develop Year 2000 solutions. Having a base-line set of terms and definitions that can serve as a foundation for such efforts is vital. The adjectives "Year 2000" (capital Y) and "Y2K" are used in this document in phrases such as "the industry must address the Year 2000 problem" or "a product is Year 2000 compliant if...". In such contexts, Year 2000 and Y2K s are defined to mean, "pertaining to computer-related issues involving the year 2000 transition or operation before the year 2000 or thereafter. Participants At the time IEEE PASC completed this standard, the Year 2000 Terminology Working Group had the following membership: Lowell Johnson, Chair Kevin Lewis, Technical Editor The following persons were on the balloting committee: (To be supplied by IEEE) Contents 1. Overview 1.1 Scope 1.2 Purpose 1.2.1 Concepts 1.2.2 Definitions 1.2.3 Annex A 2. References 3. Concepts & Definitions Draft Standard for Year 2000 Terminology 1. Overview The Year 2000 appears to be a simple problem that is intuitively understood. But when examined closely, the solutions are varied and complex in nature. The essence of this problem is the representation of the year as a two-digit number within computer systems and other technologies. This representation may cause malfunctions to occur when a system date or application date crosses the year 2000 (whether that is the actual arrival of the date or for date processing purposes) or when the system or application must reach back into the 20th century after January 1, 2000. These malfunctions can include: * Arithmetic calculations, * Comparisons * Sorting or sequencing * Incorrect recognition of leap years * Conflict with "00" and "99" as values designated with meanings unrelated to date data * Rolling over of system date data, filling up storage registers * Failure of one or more system elements Among the environments in which mission-critical applications may be affected by Year 2000 issues include: * Bio-medical * Telecommunications/transportation * Finance/Banking * Aviation/Aerospace * National security/law enforcement Many organizations are in various stages of addressing this problem. Some are just beginning to assess the impact on their own information technology (IT) environments. Others have already begun to implement solutions. The rising need for solutions has created a market environment wherein there are a growing number of organizations offering such solutions. These organizations have also created a diverse set of terms. Many of the terms are similar on their face but have multiple meanings within differing environments, bringing potential for confusion to what should be a simply understood problem. This document identifies definitions and concepts that have broad applicability to this area of work. The open, voluntary, consensus method has served as the means by which the industry has accomplished this, using the accredited standards process as the foundation for this work. A common lexicon within which the terminology and concepts are understood is vital. The information technology (IT) industry's use of the terms outlined in this document will minimize confusion. In addition, they will enhance the progression of vitally needed solutions by providing a common base of accepted definitions upon which these solutions can be developed. 1.1 Scope This standard identifies definitions applicable to the Y2K problem in computer systems applications. 1.2 Purpose This standard supplies common terms, their definitions, and related concepts for people working on the Y2K problem This document is comprised of the following parts: 1.2.1 Concepts These are a set of interrelated ideas pertaining to the Y2K issue. This document offers an explanation of these concepts based on industry consensus achieved in this document's development. 1.2.2 Definitions These are focused meanings of terms fundamental in the resolution of the Y2K issue. Vendors who claim that their products conform to this standard declare that their use of the term "Year 2000 Compliant" and of defined terms within its definition are in accordance with the definitions in this standard. 1.2.3 Annex A This annex outlines remediation techniques currently being used to make system elements Y2K compliant. This list of techniques is not exhaustive. It represents only those techniques that the IEEE P2000.1 committee acknowledges as having gained a significant amount of industry consensus. Along with the techniques is a list of supporting terms and their explanation, which the committee determined to be pertinent. In addition, the [#moreAnnex] annex briefly explains the role of special dates in the development of Y2K functionality. This annex is intended to be normative. 2. References This standard shall be used in conjunction with the following publications. If the following publications are superseded by an approved revision, the revision shall apply. ISO 8601:1988, Data elements and interchange formats -- Information interchange -- Representation of dates and times ANSI X3.30: 1985, Representation for Calendar and Ordinal Date for Information Interchange FIPS PUB 4-1, Representation for Calendar Date and Ordinal Date for Information Interchange, Change Number 1, March 25, 1996 DISC PD2000-1, A Definition of Year 2000 Conformity Requirements (a British Standards Institute publication) General Services Administration Federal Acquisition Rule (FAR) 39.002, (Federal Register 66 FR44830), August 22, 1997 General Services Administration White Paper entitled "Year 2000", August 1997 3. Concepts and Definitions 3.1 Concepts 3.1.1 Valid Date Interval (also known as Compliance Date Range): The period of time, expressed by a range of dates, over which date data will be accurately processed in a given system. The system elements or other factors may limit this interval or may introduce multiple intervals. For example, an application may process dates to year 2075 while the operating system may not process dates beyond year 2038. The system elements include operating system, hardware, firmware, or the application itself. 3.1.2 Event Horizon (also known as Time Horizon to Failure): The time from present date until the point at which a system element will fail. For example a company which issues purchase orders for one year must be able to enter valid dates in the year 2000 on January 1, 1999; therefore the time horizon to failure for this system if today were June 1, 1997 would be eighteen months. Event Horizon generally refers to all of the fixes which are required within a given time period. 3.1.3 Y2K life cycle: A conversion model comprised of five phases each representing a major Y2K activity. Both the private and public sectors have used this model in addressing their respective Y2K issues. The five phases are described below: * Awareness: define the year 2000 problem and gain executive level support and sponsorship * Assessment (inventory): Evaluate the year 2000 impact on the enterprise; develop contingency plans to handle data exchange issues and system failures (dysfunction or system crashes); triage (prioritize) systems by identifying those that are mission critical. * Remediation (renovation): convert, replace, or eliminate one or more system elements ; modify interfaces * Validation (audit): test, certify and validate converted or replaced one or more system elements * Implementation: Place into production converted or replaced one or more system elements. 3.2 Definitions 3.2.1 Certification: the act of providing written testimony of qualification of a process or product. Process certification does not necessarily mean product certification. 3.2.2 Date exchange: the interchange of date data between two or more system or system elements. In order to facilitate proper date data exchange between two or more system or system elements, defined formats should be identified and documented by the suppliers of system or system elements. Such formats may include the standards listed in Section 2, other generally accepted industry date representations, or other documented methods of date representation. 3.2.3 Date processing: the handling of date data within a system or system element 3.2.4 Year 2000 compliant: technology, including but not limited to, information technology, embedded systems, or any other electro-mechanical or processor-based system, when used in accordance with its associated documentation, is capable of accurately processing, providing, and/or receiving date data from, into, and between the twentieth and twenty-first centuries, and the years 1999 and 2000, including leap year calculations; provided that all other technology properly exchanges date data with it. Annex A (normative) This annex is normative and contains more detailed information on Y2K concepts, terms and techniques which are emerging with strong consensus within the IT community. Annex A A.1 Remediation A.1.1 Methods of Remediation A.2 Supporting Terms A.3 Special Dates A.1 Remediation This concept embodies one or more processes to repair or eliminate malfunctions relating to year 2000 date data handling under a pre-determined set of criteria. The following is a non-exhaustive list of possible remedies: * expanding the year field to four digits (field expansion) * encoding four-digit year information into an existing field (encoding) * using a 100-year logic window (window) * employing a date data bridge that converts date formats (bridge) * replacing one or more system elements (replacement) * retiring the system (elimination) A.1.1 Methods of Remediation The industry currently reflects strong consensus that there is NO ONE fix for all applications. A range of fixes can, and will most likely, apply. Fixes will be dependent on the operating environment and the prevailing factors within, such as the degree of interface the application has with other applications, or the level of date data processing within or across applications. The following methods include some of the most common fixes being implemented in the industry. This list does not describe a number of low usage or proprietary remediation methods in use (e.g. the technique referred to as 28-year encapsulation technique) . A.1.1.1 Bridge: this is a conversion mechanism that changes data elements to reconcile format differences between system elements. Date-related bridges format dates in such a way that they can be accepted and acted upon properly. For example, a bridge might be a program that is invoked to change a two-digit date field in a sending application to a four-digit date field in a receiving application when date data is transferred between the two system elements. A.1.1.2 Elimination: The retirement of a system or application no longer deemed necessary. A.1.1.3 Encoding (also called Encryption, Offset Counter Format, or Integer Date Format) Unlike field expansion, encoding allows current field widths to be maintained by storing additional information into existing fields. A more efficient use of bits may allow inclusion of century information. For example, by converting the data type from ASCII to binary, larger numbers can be stored in the same field. Similarly, if the numbering system was changed from decimal to hexadecimal, two-digit year values greater than 99 could be stored. A.1.1.4 Field Expansion: A technique that converts existing data and programs by lengthening the year field from two-digits to four-digits. A.1.1.5 Replacement (also called Migration): A process which requires the retirement of a system or system element which is determined to be necessary, but will not be made Year 2000 compliant. The system, system element, or data is moved to an alternate Year 2000 compliant system or system element. A.1.1.6 Windowing (also called Logic Fix): Any of several procedural techniques that are based on the addition of logic to infer the century value given a two-digit year. These are generally categorized into "Fixed Windowing", and "Sliding Windowing" techniques Use of this method of remediation depends on knowledge of: * the date format used across interfaces * the pivot year used * the method of changing or "sliding" the pivot year, where applicable * a description of the error handling/reporting when exchanged date data is not in the expected date format A.1.1.6.1 Windowing, Fixed: A procedural technique in which two-digit year values are interpreted within a fixed 100 year window which is typically documented in terms of a range of years (e.g., 1950 to 2049) or in terms of a pivot year (e.g., a pivot year of 50 causes values between 50 and 99 to be interpreted as 1950 to 1999, and values between 00 and 49 to be interpreted as 2000 to 2049). A.1.1.6.2 Windowing, Movable: A procedural technique in which two-digit year values are interpreted within a 100-year window, which may be user- or installation- specified. The window bounds or pivot year can be specified when the system is installed or started. A.1.1.6.3 Windowing, Sliding: A procedural technique in which two-digit year values are interpreted within a 100 year window which is defined in terms of the current date. With this technique, as the current date moves forward, year to year, the window also moves or "slides" forward. Sliding windows are typically documented by specifying a value or a set of values which when added to the current year define the bounds of the window. Thus, for example, a sliding window documented as "-40" defines a pivot year of 57 (i.e. 1957) in 1997 and 58 in 1998. Similarly, a sliding window documented as "-40, +59" defines window bounds of 1957 to 2056 in 1997 and 1958 to 2057 in 1998. A.2 Supporting Terms A.2.1 Date Counter Overflow: The point in time at which the value contained in a "date" variable causes a failure of a logical operation within an application. This misinterpretation of the "date" value may be due to a roll-over (similar to an odometer", by the value being interpreted as a negative number, or by an "overflow" flag being set in a processor status word. Date counter overflows may occur before, during, or after the Year 2000. A.2.2 Embedded System: any device that includes one or more microprocessors, not independently programmable by the user, to support its proper operation A.2.3 Filter: The blocking or passing of data based on specified criteria A.2.4 Internal system date: a date, normally not user-recognizable, set within a computer system A.2.5 Pivot Year: When a windowing remediation technique is used, dates continue to be represented with two-digit years, but are interpreted within a 100-year window, for example, 1950 to 2049. A pivot year is a two-digit value that can be used to document and interpret a windowed date. Any two-digit year value greater than or equal to the pivot year is interpreted as having a prefix of "19", while any two-digit year value less than the pivot year is interpreted as having a prefix of "20". Thus, for example, in a system supporting a 1950 to 2049 window, the pivot year of 50 causes year values between 50 and 99 to be interpreted as 1950 to 1999, and year values between 00 and 49 to be interpreted as 2000 to 2049. A.3 Special Dates There are two forms of special dates: reserved dates and test dates. Some or all of the dates listed may not be appropriate for the testing of a specific system element because, for example, the system element may not be date sensitive, or does not represent dates as calendar dates (e.g. using ordinal dates or system clock values instead), or because the dates are outside the system element's valid date range. A.3.1 Reserved dates: these are dates with special meaning such as using 9999 in a year field signifying an entry in a database that never expires. They consist of special values that are equivalent in their type to dates, but are composed of non-date values such as spaces, 000000, or 999999 in date fields. Reserved Dates have been used frequently in the past to represent items that never expire, or have other special meanings. A.3.2 Test dates: these are dates useful to an organization to determine if a system element performs correctly. Examples could include: * December 31, 1999 Last day before the year 2000 (rollover event) * January 1, 2000 First day affecting all systems that were programmed to handle only the years 1900 to1999. First date with a "00" abbreviated year. First month beginning on a weekend date. * February 29, 2000 First leap day after the rollover A more exhaustive list of test dates is included in the IEEE P2000.2 Year 2000 Test Methods document.