Prepared by the Year 2000 Terminology Working Group of the

Portable Applications Standards Committee

Copyright © 1998 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, US

Introduction *

Participants *

1. Overview *

2. References *

3. Concepts and Definitions *

Annex A – Techniques, Terms, and Special Dates (informative) *

Annex B – Rationale: Methodology and Exclusions (informative) *

Annex C – Bibliography (informative) *

(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.

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

Michael Aisenberg

Steve AllenMichael BerensLeonard Brush

George Cherry

Cory Claymon

Joe Clema

Bob Cohen

Johnetta Colbert

Eldon Colby

Don Cragun

John Davies

Christina Drukala

Amy Fliegelman-Olli

Trutz Foelsche

Lee Gallagher

Bob Gniewkowski

Debbie Goldberg

Joe Gwinn

Tim Harris

JoAnn Henderson

Richard Holleman

Vincent Hung

Jim Isaak

Petr Janecek

Margaret Jedlicka

Lowell Johnson

Andrew Josey

Yong Kim

C. W.Klein

Tom Koenig

Cheryl Lai

Kevin Lewis

Rex Lint

Mickey Lynn

Austin Maher

Robert Martin

Roger Martin

Richard McLean

James Murray

John Napier

Alan Peltzman

Carolyn Price

Bill Pritchett

Bill Putnam

Larry Schwartz

Philip Simons

Terrill Slocum

Nick Stoughton

Robert Swartz

Keith Thurston

John Tyler

Roger Tyler

Richard Vasquez

Michael Wheatley

Laurence Wolfe

Dave Wong

Gary Young

The following persons were on the balloting committee:

(To be supplied by IEEE)

The Year 2000 issue 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 in hardware and software elements of computer systems and other technologies. This representation may, for example, cause hardware or software malfunctions to occur when a system date or application date crosses the year 2000 boundary (whether that is the actual arrival of the date or for date processing purposes) or when the system or application must refer to a date that occurs on, before, or after January 1, 2000. These malfunctions can include:

• Incorrect arithmetic calculation, comparison, sorting or sequencing resulting in the failure of logical, relational, and set-membership operations

• Incorrect recognition of leap year
• Conflict with values in data fields used for non-date purposes, e.g., "no date provided", or "never expires"
• Date data field overflow

The impact of the Year 2000 problem is potentially significant to virtually any segment of the global digital infrastructure and the economies it supports. Among the environments in which mission-critical applications may be affected by Year 2000 issues are:

• Bio-medical
• Telecommunications/transportation
• Finance/banking
• Aviation/aerospace
• National security/law enforcement
• Other critical infrastructure (e.g. water/waste treatment plants, energy/power generation and transmission)

As this document is being prepared, 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 an easily understood problem.

This document identifies common terms, definitions, and related concepts that have broad applicability to this area of work. Those presented herein may be applied wholly or in part to fit a specific requirement..

A lexicon within which the common terms, definitions, and related concepts are understood is vital. The IT industry’s use of those terms defined in this document will minimize confusion. In addition, having common terms, definitions, and related concepts will speed the development of urgently needed solutions. This standard describes what these terms, definitions, and related concepts mean, not how to implement or verify Year 2000 compliance.

It is not the intent of this standard to specify how Year 2000 compliance should be implemented or verified

This standard identifies terms and concepts pertinent to the resolution of the Year 2000 issue and provides definitions of these terms and descriptions of these concepts.

This statement of scope focuses specifically on the changeover from the year 1999 to the year 2000. It does not include dates such as the year 2038, a commonly known operating system problem considered outside of the scope of this document.

This standard provides a common lexicon with descriptions and definitions to the information technology industry for use in the development of Year 2000 solutions. These descriptions and definitions may be applied in whole or in part depending on the requirement.

This document is composed of a Concepts and Definitions section, Concepts and Definitions subsections, and a set of Annexes.

A concept is a set of interrelated ideas pertaining to the Year 2000 issue. This document offers a description of these concepts. . This is not an exhaustive list. .

These are focused meanings of terms fundamental to the resolution of the Year 2000 issue.

This annex outlines remediation techniques currently being used to make system elements Year 2000 compliant. This list of techniques is not exhaustive. It presents only those techniques acknowledged as having gained a significant amount of industry consensus. Along with the techniques is a list of supporting terms and their explanation. In addition, the annex briefly explains the role of special dates in the development of solutions for the Year 2000 problem. This annex is informative.

This annex outlines the methodology used in the development of this document. It identifies specific exclusions and explains the rationale for such. This annex is informative.

This is a bibliography listing other related publications.

Vendors who claim that their products conform to this standard declare that their use of the term "Year 2000 Compliant" is in accordance with the definition in this standard.

This standard shall be used in conjunction with the following publications:

ANSI X3.30: 1985, Representation for Calendar Date 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

ISO 8601:1988, Data elements and interchange formats -- Information interchange -- Representation of dates and times

The term "system element" where used in this document refers to any individual component of a computer- or microprocessor-based system which participates systematically in a specific process. System elements may include hardware components, firmware routines, operating systems, middleware components, application programs, system utilities and subroutines, scripts, and the like.

3.1.1 Valid Date Interval (also known as Compliance Date Range): The period of time, expressed by a range of dates, over which. the system will provide correct date data processing. The system elements or other factors may limit this interval or may introduce multiple intervals. For example, on a system capable of operation between 1970 and 2038, applications may be capable of correctly processing date data over a much wider range of dates, such as 1970 through the year 2069.

The time from a specific date until a point in time beyond which a system element will fail to process consistently, predictably or accurately. An application which processes dates up to 12 months in the future might fail on or after January 1, 1999 if it was unable to process dates beyond December 31, 1999. Therefore, on September 1, 1998, the time horizon to failure for this application is four months. Since each element of a system potentially has its own unique horizon, the horizon of the entire system is that of the earliest-failing element within it.

3.1.3 Year 2000 Life Cycle: A conversion model composed of five phases each representing a major Year 2000 activity. Both the private and public sectors have used this model in addressing their respective Year 2000 issues. The five phases are described simply and very briefly below:

• Planning and Awareness: Define the Year 2000 problem and gain executive level support and sponsorship for establishing the problem as a high priority item for resolution. Research and establish a project plan, obtain budget and resources. Note that the planning activities are also relevant to the other phases described below.

• 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); prioritize systems by identifying those that are mission-critical

• Remediation (renovation): Convert, replace, eliminate, workaround, or encapsulate one or more system elements; modify interfaces

• Validation (audit): Test, certify, and validate all system elements that have been converted or replaced

• Implementation: Place into production all system elements that have been converted or replaced

3.2.1 date exchange: The interchange of date data between two or more systems or system elements. In order to facilitate proper date data exchange between two or more systems or system elements, defined formats should be identified and documented by the suppliers of systems or system elements. Such formats may be specified by the standards or other publications listed in Section 2, other generally accepted industry date representations, or other documented methods of date representation. Depending upon the date formats selected, additional information such as, but not limited to, valid date interval, pivot year, and encoding technique may also need to be documented.

3.2.2 date processing: The processing of date data within a system or system element which may include receiving, manipulating, and providing date data.

3.2.3 technology: Hardware, software, and firmware systems and system elements including but not limited to information technology, embedded systems, or any other electro-mechanical or processor-based systems.

3.2.4 year 2000 compliant: Year 2000 compliant technology shall correctly process date data within and between the 20^th and 21^st 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.

This annex is informative and contains more detailed information about selected Year 2000 concepts, terms, and remediation techniques which are becoming commonly used in the IT community. This is not intended to be either a comprehensive or a preferred listing of approaches.

> > 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 techniques or strategies that have been employed in the > remediation > > process. These > techniques are not necessarily mutually exclusive and not > necessarily > sufficient in and of themselves to solve the problem:

• Bridge - employing a date data bridge that converts date formats
• Elimination - retiring the system

• Encoding - encoding four-digit year information into an existing field

• Field expansion - expanding the year field to four digits
• Replacement - replacing one or more system elements
• Windowing - using a 100-year logic window

There is general agreement within the industry that there is NO SINGLE method of remediation that can be applied to all situations. In any given situation, the method chosen will depend on the operating environment and other factors such as the prevalence of interfaces with other applications and the amount of date data processed within or between 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.

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 sizes to be maintained by storing additional information into existing fields. A more efficient use of bits may allow inclusion of century information. This may be accomplished, for example, by using unused bits in an existing representation to encode century information, or by converting the data type from ASCII to binary in order to allow larger numbers to be represented 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 fields from two-digits to four-digits.

A.1.1.5 Replacement: Retirement of a system or system element which is not Year 2000 compliant and replacement of it by another system or system element which is Year 2000 compliant.

A.1.1.6 Windowing (also called Logic Fix): Any of several procedural techniques based upon the addition of logic that uses a specified 100-year interval to interpret a 2-digit year value as an unambiguous 4-digit year. The procedural techniques commonly used are typically categorized into "Fixed Windowing", "Movable Windowing", and "Sliding Windowing". Use of this method of remediation depends on knowledge of:

• the date format used across interfaces between two or more system elements
• the pivot year used (see A.2.4)
• 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 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. The window is typically documented in terms of a range of years (for example, 1950 to 2049) or in terms of a pivot year (for example, a pivot year of 1950 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 range of years in the window or the 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 sometimes documented by specifying a value (usually called a "slider") which when added to the current year defines the pivot year of the 100 year window. Thus, for example, a sliding window operating on a current date of February 2, 1998 with a "slider" defined as ‘-40’ would result in a pivot year of 1958 (1998-40) and a window range of 1958-2057. On February 2, 1999, the pivot year would be 1959 (1999-40) and a new window range of 1959-2058.

A.2.1 date counter overflow: The condition that occurs when the value contained in a "date" variable causes a failure of a logical or arithmetic operation within an application. This anomalous condition is usually caused by an incremental date value exceeding the capacity of its definition, the resulting effect being interpreted as a zero or negative number, or by an "underflow" or "overflow" condition by the processor. Date counter overflows may occur before, during, or after the year 2000.

A.2.2 internal system date: A date, normally not user-recognizable, within a computer system.

A.2.3 leap year: a year is a leap year if it is a multiple of 400, or if it is a multiple of 4 AND NOT a multiple of 100. Thus, 1996, 2000, and 2004 are leap years, but 1900, 1997, and 2100 are not.

A.2.4 pivot Year: A pivot year is a value that is used to specify the beginning of a 100-year window and to interpret 2-digit year dates within that window. In a window that spans the year 2000 boundary, any two-digit year value greater than or equal to the last 2 digits of the pivot year is interpreted as having a prefix of "19", while any two-digit year value less than the last two digits of the pivot year as having a prefix of "20". Thus, for example, in a system supporting a 1950 to 2049 window, a pivot year of 1950 causes two-digit year values between 50 and 99 to be interpreted as 1950 to 1999, and two-digit year values between 00 and 49 to be interpreted as 2000 to 2049.

There are two forms of special dates: reserved dates and test dates.

Some or all of the dates listed need not be appropriate for the testing of a specific system element because the system element may not be date sensitive, or does not represent dates as calendar dates (for example, 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: Reserved dates 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. There are occasions when valid date values that have special meanings are stored and used as flags.

A.3.2 Test dates: Test dates are dates useful to an organization to determine if a system element performs correctly. Examples include:

• December 31, 1999 Last day before the year 2000 rollover

• January 1, 1999 "First day affecting all systems that were programmed to recognize 9s in a special way such as "save forever" and "end of data"

• 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.

• February 29, 2000 First leap day after the year 2000 rollover

This annex contains the rationale outlining the approach taken in the development of this document. It summarizes the reasoning behind the content, how the content was determined, and identifies topics that were excluded and the accompanying rationale for their exclusion. (This annex will not appear in the final published standard.)

It was quite clear in the early stages of this effort that this entire area is overwhelming. The consensus developed early on that any effort here needed to be focused, concise, and expeditious. Given that basic set of criteria, the group outlined a set of boundaries:

• The focus would be on the year 2000 transition only
• Compliance as a definition needed to be addressed
• Any compliance definition must not exclude solutions currently acceptable by industry as a whole, thereby necessitating that this definition have breadth
• A minimum set of performance expectations must be outlined in order to be feasible
• The standard must not specify specific date formats but must speak to the role of date formats within the context of compliance

The objective here is to provide a standard that can serve as a key reference point as organizations develop and/or procure Year 2000 solutions. Concurrently, it is vital to underscore here that it is not a silver bullet (as is no specific solution). Many other terms and concepts could have been included but the time criticality dictated that this document remain very focused in order for it to properly proceed through the standards process in a timely fashion.

This term was initially included in the document but, as a result of the first round of balloting, was later excluded. It is essentially a slang term use more in conversation and dialogue and was deemed not apropos for a written, formal standard.

Many systems which use a fixed size binary counter to record time in terms of an offset from a fixed date like Jan. 1, 1970 may encounter problems as soon as 2038. This has been a known problem long before the Year 2000 gained prominent attention, and efforts to resolve it are outside the scope of this document.

This is a technique that was initially proposed as a silver bullet. With further scrutiny, it became apparent that this is essentially a low use, proprietary technique that has not demonstrated effectiveness or general acceptance. Including it in the document would raise its visibility to a level incongruent with its acceptability.

This term was purposely omitted. As stated in the overview section, this document does not specify how compliance, which is the essence of this document, should be verified. The focus of this document is to define compliance and other pertinent terms. Addressing certification within the context of Year 2000 compliance is beyond the scope of this effort.

[B1] DISC PD2000-1, A Definition of Year 2000 Conformity Requirements (a British Standards Institute publication)

[B2] General Services Administration Federal Acquisition Rule (FAR) 39.002, (Federal Register 66 FR44830), August 22, 1997, 48 CFR Parts 39 and 52, [FAC 97-01; FAR Case 96-607; Item XVII], RIN 9000-AG90

[B3] General Services Administration White Paper entitled "Year 2000", August 1997, FEDSIM Project Number 88025GSE - 07