The following Y2K material has been kept available by MITRE for historical purposes only and has not been updated unless noted.
MITRE - Y2K - GTE Criteria
Proposed Criteria for "Century Compliance"
For the most recent version of this document dated 1996-09-24 (in PDF format only), please see GTE's website.
DISCLAIMER
This working technical document was prepared solely
for the internal use of GTE Corporation and affiliated GTE companies
(GTE). GTE EXPRESSLY DISCLAIMS ANY RESPONSIBILITY FOR THE ACCURACY
OR COMPLETENESS OF THE CONTENTS OF THIS DOCUMENT WHICH IS PUBLISHED
"AS IS." GTE FURTHER DISCLAIMS ALL EXPRESS OR IMPLIED
WARRANTIES OF ANY KIND, INCLUDING WARRANTY OF FITNESS FOR A PARTICULAR
PURPOSE OR WARRANTY OF MERCHANTABILITY. Reliance on or use of
the information contained herein shall be at the user's sole risk.
GTE shall not be held liable for any damages of any kind including
direct, consequential or special damages which may arise out of
or result from reliance on or use of the information in this document.
This document is copyrighted by GTE Government Systems Corporation.
Copyright 1995, 1996 GTE Government Systems
Corporation.
PA96014
Revised 1996-06-19
GTE Technology & Systems
Technology Program Office
Waltham, MA 02254
Proposed Criteria for "Century
Compliance"
Summary
This paper presents proposed criteria for "century compliance."
It first provides information regarding the scope of the Year
2000 (Y2K) challenge and then identifies and discusses four suggested
criteria for consideration in assessing century compliance.
A term commonly used in industry is "year 2000 compliant."
Inherent in this term is an important but narrow focus on the
year 2000 deadline and the problems associated with that single
event. In contrast, this paper uses the term, "century compliant,"
to emphasize the broader character of the Y2K challenge.
The philosophy underlying this paper considers that compliance
involves business and technical considerations.
Accordingly, century compliance requires a balance between cost
and minimizing the technical risks in the solution.
This paper replaces all previous versions.
Background of the Y2K Challenge
Widespread understanding of the Year 2000 (Y2K) challenge is an
emerging phenomenon. While technologists understand the many
intricacies in how computer software handles dates, explanations
in the media and elsewhere tend to simplify the problem for brevity.
Descriptions of the Y2K phenomenon are typically straightforward.
Software commonly carries only the lower two digits for each
year and, as a result, ignores century when manipulating dates.
Once software begins mixing dates in both the 19xx and 20xx ranges,
errors of varying degrees can result. In some cases, the software
may fail immediately without completing its operation. In others,
the software may continue to produce erroneous output, which can
remain unnoticed.
Essence of the Challenge
There has been extensive examination of the Y2K challenge and
ways to address it. These include but are not limited to:
Essential Y2K program activities (inventory, impact assessment,
etc.)
Prioritizing, scheduling, and coordinating conversion projects
Vendor management
Sizing the Y2K effort
Options for representing and manipulating date data
Methods for converting existing applications
Inventory and conversion tools
While examining various aspects of this subject is vital, the
considerations discussed above are actually elements of the solution--not
the problem. Technical experts tend to talk about what changes
are needed in how software handles and stores date data. Program
managers tend to talk about planning, estimation, and inventory.
Higher-level managers tend to talk about the cost and the diversion
of resources. Each person struggling with the Y2K challenge tends to focus on that part of the solution uppermost in his or her mind.
The first step in addressing the Y2K challenge is to identify
the business considerations which include:
Eliminating century risk. In reality, this risk can
only be eliminated for a period of time--the longer the period,
the greater the cost.
Preserving current operations. Changes to achieve compliance
should have minimal affect on the cost and efficiencies of current
operations.
Minimizing conversion burden. The company must minimize
resources diverted to the Y2K effort.
Compliance is a balance between lower cost and lower risk. Table
1 lists seven measurements that more fully characterize the business
and technical needs that should be considered in developing a
Y2K program.
The challenge in defining compliance is to enable implementation
plans that address the business needs while satisfying the following
considerations:
Assure that all aspects of the Y2K challenge are adequately
covered
Encompass a full spectrum of cost-benefit-risk trade-offs
Permit wide latitude in adopting technical and programmatic
solutions
This paper attempts to encourage solutions that minimize Y2K risk
while minimizing the cost of Y2K conversion.
Technical Elements of the Y2K Challenge
The technical component of the Y2K challenge revolves around accurately
accepting, creating, manipulating, and outputting calendar-related
data. The largest concern is whether software can handle the
date roll-over to the year 2000. This date change constitutes
a high-risk event that conversion efforts should mitigate.
Measurement
Description
Time to Next Y2K Event (TNYE)
Also called the "event horizon." Numerous events associated the Y2K challenge can occur at any time. Y2K conversions cannot eliminate these events for all time but can keep the next one from occurring until many decades into the future. In general, Y2K conversions will increase this margin in some rough proportion to the cost of the conversion. The balancing of cost and technical approach should maximize the value for TNYE.
Incremental Complexity
Software complexity can be measured using several methods. Some approaches in Y2K conversion will increase this complexity and consequently reduce maintainability and reliability. Trade-off should minimize software complexity.
Delta Cost Performance
Each system has a predictable cost for operation and maintenance. Some approaches to Y2K conversion tend to increase these costs (for permanent storage for example). The balancing of cost and technical approach should minimize the average cost per month.
Delta Technical Performance
Technical performance measures such as throughput and turnaround may suffer with some approaches to Y2K conversion. Trade-off should minimize (e.g., turnaround) or maximize (e.g., throughput) each performance measure as appropriate.
Delta Conversion Cost
Approaches to the Y2K challenge vary in cost. Regardless of incremental benefit, there are limits to affordability. The balancing of cost and technical approach should minimize this cost to the extent feasible.
Delta Conversion Schedule
Approaches to the Y2K challenge vary in duration. Regardless of incremental benefit, some approaches may not be completed before the first Y2K event. Trade-off should minimize this schedule.
Delta Conversion Risk
The risk of slipping schedule or overrunning cost for an organization's entire Y2K program is a measure of the organization's probability of survival. Each approach to Y2K conversion includes risks. The level of testing is one critical consideration in analyzing the risks of each approach. Trade-off should minimize the value for risk exposure. (Risk exposure is risk probability times potential cost.)
Table 1. Measurements Characterizing the Trade-Offs
to Achieve Century Compliance
Century compliance, however, is larger than the roll-over to 2000.
There are several other risk areas whose events are associated
with the Y2K challenge. These events can occur not only at the
roll-over to 2000 but well before and well after. Table 2 enumerates
the various elements of the Y2K technical issue and examples of
events associated with them. It is important to understand that
alternatives for addressing each element share considerable overlap.
Element
Description
Example event
Probable timing
Century ambiguity
This is the most common element. Software represents dates with a 1- or 2-digit year. When software does not recognize that dates are not all in the 19xx range, the results are undesirable. Examples:
Examples of century ambiguity can appear in the following events:
Examples of events can occur with timing as early as:
a. Data edits reject years in early 20xx as invalid.
a. Bank ATM rejects an other-wise valid bank or credit card with an expiration date of "00".
a. First use of cards issued in 1995.
b. User interface does not allow 4-digit year to clarify century.
b. Lotus 1-2-3 accepts only 2-digit years which it assumes to be in 19xx only.
b. First need to enter values later than 1999. Has already occurred.
c. Sorting leaves dates in 20xx and 19xx in jumbled order.
c. Itemized monthly bill lists transaction for Jan 1, 2000 through Jan 15, 2000 followed by Dec., 19, 1999 through Dec., 31, 1999.
c. First monthly data processing in 2000.
d. Durations such as invoice aging are calculated incorrectly.
d. Invoice age calculated as ridiculously large number or as negative number, erroneously triggering overdue notices and staggering interest penalties.
d. January, 2000.
e. The century is truncated or changed between entering and retrieving a date.
e. Software stores dates in the 20xx range using DMBS but only passes 2-digit years to the product. DBMS defaults to 19xx and stores.
e. Could happen in 1996 for systems with 5-year time horizon.
f. Comparing a date in 19xx with a date in 20xx assumes both are in 19xx.
f. Payroll-deduction calculations for years in 20xx incorrectly mistake the year as 19xx and fail to apply recent changes in tax laws.
f. First quarter of 2000.
Table 2. Technical Elements of the Y2K Challenge
Criteria for Century Compliance
This proposal for century compliance requires that software satisfy
four, date-related criteria. Software meeting all four can be
considered "century-compliant." These criteria are
listed in Table 3.
Element
Description
Example event
Probable timing
Extended semantics
In general, specific values for a date field are reserved for special interpretation. The most common example is interpreting "99" in a 2-digit year field as an indefinite end date, i.e., "does not expire." Another is embedding a date value in a non-date data element.
Some software may erroneously process a transaction with a valid end date in 1999-such as not terminating an expired software license or failing to age back-up tapes for recycling as scratch tapes.
Will occur on various days after Dec. 31, 1998.
Calendar errors
Errors typically include failing to treat 2000 as a leap year and converting incorrectly between date representations.
Logic sensitive to day-of-week will be one day off after February 28, 2000. Calculating day of week for all dates following this will be incorrect.
Will occur the first time input data contains Feb. 29, 2000. Will occur on this leap day.
Date overflow
Many software products represent dates internally as a base date/time plus an offset in days, seconds, or microseconds since that base date/time. Hardware integers holding the offset value can overflow past the maximum corresponding date-an event which may lead to undefined behaviors.
Value for date can revert to a date near the base date/time, to a negative value, or crash the software because of an illegal operation.
Happened in the 1980s on certain Tandem hosts. Could happen again at any time to any product depending on how product stores dates.
Inconsistent semantics
At interface between systems, software on each side assumes semantics of data passed. Software must make same century assumptions about 2-digit years.
Software on one side assumes all dates in 19xx. Software on other side assumes years 51-99 are 19xx, and 00-50 are 20xx.
Could happen in 1996 for software that stores date values 5 or more years into the future.
Table 2. Technical Elements of the Y2K Challenge
(Concluded)
Each criterion serves as a high-level requirement for software.
The following discussion elaborates on each:
General integrity. As a system date advances normally
on a host processor, each date roll-over must not lead either
the host process nor any software executing there to erroneous
processing. The best recognized, high-risk, date change is the
roll-over to 2000. The term, "desired operation," in
Table 3 is intentionally broad and must be interpreted for specific
technologies and applications.
Criterion
Description
General integrity
No value for current date will cause interruptions in normal operation.
Date integrity
All manipulations of calendar-related data (dates, durations, days of week, etc.) will produce desired results for all valid date values within the application domain.
Explicit century
Date elements in interfaces and data storage permit specifying century to eliminate date ambiguity.
Implicit century
For any date element represented without century, the correct century is unambiguous for all manipulations involving that element.
Table 3. Four Criteria for "Century Compliance"
Date integrity. This criterion primarily covers the
correctness of manipulations of date data as enumerated in Table
4. These manipulations need to be reliable only over the range
of dates that an application is expected to handle. For example,
sales-order processing may handle dates from 5 years in the past
to one year in the future. In contrast, an employee database
may store dates of birth from early in the 20th century to planned
retirement dates well into the 21st century.
Explicit century. This criterion essentially requires
the capability to store explicit values for century. For
example, third-party products that can use a 4-digit year in all
date data elements stored and passed across each interface (including
the user interface) would satisfy this criterion. A base-and-offset
representation of dates that covers all centuries of interest
would also satisfy this criterion. Whether this capability should
be used to eliminate century ambiguity is part of the last criterion.
Implicit century. This last criterion requires that,
if the century is not explicitly provided, its value can be correctly
inferred with 100% accuracy from the value of date provided.
For example, the range of values for an "invoice date"
would very rarely span more than 10 years. Because the century
can always be guessed correctly for an invoice date with a 2-digit
year, this date data element would satisfy this criterion. Note
that his criterion permits cost-risk trade-offs that minimize
changes to existing date formats.Interpretation of the Criteria
Although the four criteria fully define century compliance, compliance
represents a balance between cost and risk rather than an absolute
"yardstick." Such a balance will vary with each organization
according to its business needs and its technological base. Consequently,
an organization will require a greater level of detail to interpret
how these criteria apply to the organization. An interpretation
documented and distributed can assure that "century compliance"
is interpreted consistently across the organization.
Category
Examples of manipulation
Arithmetic
Calculate the duration between two dates
Calculate date based on starting date and duration
Calculate day of week, day within year, week within year
Branching
Compare two dates
Format
Convert between date representation (YMD, Julian, etc.)
Reference same data address with different variables
Data storage
Storing and retrieving
Sorting and merging
Searching
Indexing on disk file or database table
Moving data within primary memory
Extended semantics
"99" as special value for year
"99.365" as special value for Julian date
"00" as special value for year
Table 4. Variety of Manipulation of Date Data
Table 5 contains an interpretation of the criteria as an example.
Note the importance of clearly identifying the calendar by name,
the specific date ranges for compliance relevant to the organization,
reasonable latitude in date format, and situations under which
implicit century values will be tolerated. Also note that certain
exceptions are included to support important options for optimal
cost/risk trade-off.
Standardizing the format for date data is an important part of
century compliance. The example in Table 5 uses the ANSI X3.30
standard for date representation. For systems with interfaces
to foreign entities or U.S. government agencies, the equivalent
ISO and FIPS standards may be used instead. There are two very
important considerations with requiring conformance to an industry
standard:
Limitations in standards. None of the three standards
(ANSI, ISO, and FIPS) for date representation mandates a 4-digit
year for all calendar data. For example, conformance to ANSI
X3.30 does not eliminate century ambiguity from all date variables
and interfaces. Instead, conformance simply reduces the variety
of formats occurring within software and data.
Accommodating conflicts. While trying to conform to
ANSI X3.30, some applications may need to satisfy other standards
or conventions for date representation. Table 6 lists examples
of standards with date representations that may supersede ANSI
X3.30 in specific applications.
Criterion
Description of criterion
Interpretation of criterion
General integrity
No value for current date will cause interruptions in normal operation.
All software on all platforms will function correctly for all values of system date between 1985-01-01 and 2035-12-31.
Of special interest are the following dates and the ability to roll over to the correct next date:
All manipulations of calendar-related data (dates, durations, days of week, etc.) will produce desired results for all valid date values within the application domain.
All date values and calculations are based on the Gregorian calendar as defined in Encyclopædia Britannica, 15th edition, 1994, p. 430p.
Computing assets must correctly handle all representation and manipulation of dates with values between 1900-01-01 and 2050-12-31. Especially important is that all years in this 150-year range divisible by 4 are leap years except 1900.
All software developed for GTE must initialize all date elements with either all zeros (0000-00-00) or null values. Null values are defined for each application by the development facilities, such as language compiler. A null-value feature is strongly recommended in third-party-software selection.
All developed software must not contain literals or constants for dates unless required to capture specific business rules such as calculations of payroll deductions.
All developed software must not use special date values as logical flags, such as "99" as year to mean "no end date" or "00" to mean "does not apply."
Exceptions:
Valid date ranges in existing developed or existing third-party software may start with the oldest date value in the application's archived data rather than with 1900-01-01 when there is no business need to support earlier dates.
Table 5. A GTE Interpretive Example of Century-Compliance
Criteria
Criterion
Description of criterion
Interpretation of criterion
Explicit century
Date elements in interfaces and data storage permit specifying century to eliminate date ambiguity.
All developed and third-party software must permit the use of date formats which explicitly specify century in all date data stored or transmitted. The format of these date elements must be YYYYMMDD or YYYYJJJ as specified by ANSI X3.30-1985(R1991) unless superseded by another application-specific standard or convention.
In storing or transmitting date data, some applications must conform to domain-specific standards, contractual agreements, or APIs to necessary third-party products whose date formats must supersede ANSI X3.30 as appropriate within the application. Examples of these standards are listed in Table 6.
Third-party products must permit formatting data with explicit century in the user interface.
All developed applications using third-party products must always explicitly supply century and never rely on those products' default value for century.
Exceptions:
For date data formatted for a user interface, it is acceptable to use punctuation (slash, hyphen, period, comma) within a formatted date, to spell out or abbreviate the name of the month, or to reorder year-month-day to serve customs among the end-users.
DBMSs which cannot store date in conformance with SQL standards but do store century explicitly (such as "DD-mmm-YYYY") are acceptable.
Default values for century are permitted only when supplied by data-entry aids and the end-user can verify the defaulted value before committing the data.
Implicit century
For any date element represented without century, the correct century is unambiguous for all manipulations involving that element.
Century must be explicit in all date data stored or transmitted unless the correct century can be inferred with 100% accuracy based on the value for date. Explicit century is preferred where practical.
Developed and third-party software may imply century in the user interface in the format, YYMMDD or YYJJJ (as specified by ANSI X3.30).
In storing or transmitting date data, some applications must conform to domain-specific standards whose requirements for dates may supersede ANSI X3.30 as appropriate within the application. Examples of these standards are listed in Table 6.
Exceptions:
For date data formatted for a user interface, it is acceptable to use punctuation such as slash within a formatted date, to spell out or abbreviate the name of the month, or to reorder year-month-day to serve customs among the end-users.
Table 5. A GTE Interpretive Example of Century-Compliance
Criteria (Concluded)
Domain
Standard
Federal or DOD procurements
FIPS-4-1 (Revised 1996-03-25)
Interoperability with international concerns
ISO 8601 (1988)
SQL
ANSI X3.135-1992, ISO-IEC 9075:1992, or FIPS 127-2
Exchange of call-billing data
Bellcore SR-STS-00320 (EMI)
Call Data Records
Switch mfgs' proprietary formats
Credit cards, debit cards, ATM cards
ISO-IEC 7813, ISO 4909
Electronic commerce (EDI)
ASC X12 EDI draft std for trial use, ISO 9735, UN/EDIFACT
Table 6. Examples of Standards Which May Supersede
ANSI X3.30 for Formatting Date Data
Applying the Criteria
The detail in Tables 5 and 6 can be applied throughout an organization.
Century compliance should becomeboth a standard in normal
business operations and a fundamental specification for Y2K programs.
The following activities should adopt these criteria as a standards
in day-to-day business:
Software development. Development of new software,
both in-process and planned, should immediately adopt a standard
for century compliance.
Third-party product selection. Selection of third-party
software and intelligent hardware products should be governed
by the compliance criteria.
Service-vendor selection. Selection of vendors for
data processing, marketing data, and other services should demonstrate
compliance with these or equivalent criteria.
Compliance criteria are the most important concept in a Y2K program.
All other goals, decisions, and plans must revolve around a common
understanding of compliance. The compliance criteria in this
paper are relevant in the following tasks of a Y2K program:
Designing inventory. When inventorying software assets,
the compliance criteria can help ensure that the appropriate data
is collected. For example, if third-party products are used in
custom application software, then knowledge of non-compliant third-party
products will help identify non-compliant applications.
Impact analysis. As each computing asset is examined
for compliance, a clear statement of century compliance is essential
to ensure that all elements of the Y2K issue are identified.
For example, third-party products should be evaluated against
certification testing based on Tables 5 and 6. Table 7 suggests
guidelines for developing test cases for each criterion.
Software conversion. When deciding how best to convert
an application to achieve century compliance, the compliance criteria
should guide those decisions. For example, each date field in
permanent storage must be examined to determine what modifications
to the data and/or program logic are needed to achieve century
compliance. Figure 1 is an example of the decision process for
that field-level analysis.
Software testing. During Y2K conversion projects,
converted software must be tested to verify that it is now century-compliant
and that none of the functionality has been impaired during the
conversion. The compliance criteria should guide the design of
these tests.
Application to Impact Analysis and Testing
Testing against the century-compliance criteria falls into the
following three categories:
General. Some aspects of century compliance are independent
of technology and application domain. For example, Jan. 1, 2000
follows Dec. 31, 1999 for all hardware and software.
Technology-specific. Some aspects of century compliance
depend on the technology and the behaviors and features of that
technology. For example, not all software performs all the date
manipulations listed in Table 4.
Domain-specific. Some aspects of century compliance
depend on the requirements of a specific application. For example,
the valid ranges for dates to be tested can vary with each application.
Table 7 is a high-level guide for test cases to consider in each
category. Testing should be organized by category to permit reusing
test procedures among different applications.
Electronic interfaces (API such as O/S call for system date, etc.)
Technology-specific
Current date
Power-down continuity
"System date" versus "current date"
Date representation
Overflow of base-and-offset representation
Standards for Gregorian formats
Century capability in storage and interfaces
Date manipulation
Date arithmetic
Conversion between representations
Sorting, searching, indexing
Century designation available in storage and interfaces
Domain-specific
Century ambiguity
Accuracy in inferring century for each field in storage, user interface, and other interfaces.
Date representation
Industry standards and contract requirements
Human-factors requirements
Design and coding standards
Date manipulation
Access to archived data
Manipulation of archived data
Extended semantics
Table 7. High-Level Guidelines for Test Cases in Y2K
Test Procedures
Recommendations
Century compliance as specified in Tables 3, 5, and 6 is based
on the philosophy that the Y2K challenge must be viewed as not
only a technical but a business issue. The spirit of compliance
is to eliminate technical risks in computing assets through cost-effective
solutions.
Figure 1. Analysis of Data Fields as Guided by Century-Compliance
Criteria
Therefore, if there are several conversion options with acceptable
cost and schedule, it is recommended not simply to select the
least-cost among them but the one option that most closely attains
all the following objectives.
Explicit century. All custom and third-party software
and data explicitly represent century in all date data elements
external at software interfaces, internal to the software logic,
and stored both on-line and off-line.
Variations in representation. The number of variations
in syntax for date data elements is less than five. This
includes all internal representation (except representation internal
to third-party products), representation at all interfaces (not
counting applicable industry standards), and representation in
archived data.
Variations in user interface. The number of variations
in date syntax in the visual user interface of any application
is no more than four. The term, user interface, includes
screens, windows, character-oriented dialogues, LED read-outs,
paper reports, on-line reports, generated consumer mailings, user-accessible
logs, etc.
Event horizon. For century-compliant software, the
next Y2K event is at least 50 years away.
Common routines. All applications in the same source
language share the same date routines for all date manipulations.
Semantic extensions. All extensions to date semantics
are eliminated.
Summary
The Y2K challenge is a very urgent matter. Responding to the
challenge without some analytical discipline in the front-end
work could impede achieving timely and cost-effective century
compliance. Each organization should begin its Y2K program with
clearly articulated criteria for century compliance and then use
these criteria to guide the planning and execution of all activities.
APPENDIX A
Guidelines for Testing Century Compliance of a Commercial Telephone Switch
Compliance criterion
Guidelines for impact analysis
General integrity
System date on switch can be set to high-risk dates:
1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29
Re-initialize from cold start on high-risk dates:
1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29
System date rolls over correctly on high-risk dates:
1998-12-31 -> 1999-01-01
1999-12-31 -> 2000-01-01
2000-02-28 -> 2000-02-29
2000-02-29 -> 2000-03-01
Date integrity
Do date-sensitive services for system dates behave correctly in 19xx and 20xx?
Date-sensitive includes specific dates, days of week, and durations.
Services such as call-back, 800 routing, voice-mail operator
What is highest possible value switch can represent for system date?
System date correctly used in time-stamps for high-risk dates
High risk dates: 1998-12-31, 1999-01-01, 1999-12-31, 2000-01-01, 2000-02-28, 2000-02-29, 2000-03-01
Time stamps in call-data records, track and performance reports, data saved on hard-disk
Explicit century
Can date-sensitive services be set and used successfully for dates in 20xx?
Are there 1- and 2-digit years not covered by Bellcore standard?
Implicit century
Are there any date fields in any interface that contain a year?
Could these be misinterpreted by either side of interface for dates in 20xx?
Guidelines for Testing Century Compliance of an Operating System
Compliance criterion
Guidelines for impact analysis
General integrity
System date can be set to high-risk dates:
1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29
Re-initialize from cold start on high-risk dates:
1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29
System date rolls over correctly on high-risk dates:
1998-12-31 -> 1999-01-01
1999-12-31 -> 2000-01-01
2000-02-28 -> 2000-02-29
2000-02-29 -> 2000-03-01
Does system date roll over correctly in both powered-up and powered-down states?
Date integrity
Do date-sensitive functions for system dates behave correctly in 19xx and 20xx?
Date-sensitive refers to functions whose behavior can start or stop on a specified date, on a specified day of the week, or after a specified elapsed time.
Functions such as job scheduling, accounting, admin functions, any interactive command with dates in parameters or switches (especially disk and tape commands and utilities), setting or obtaining system date through system call, reporting system data with dates in it.
What is highest possible value switch can represent for system date?
System date appears correctly used in time-stamps for high-risk dates
High risk dates: 1999-01-01, 1999-12-31, 2000-01-01, 2000-02-28, 2000-02-29, 2000-03-01
Time stamps in queue entries, volume directories, inter-process communication, off-host communication.
Explicit century
Can century be explicitly entered or displayed in date-sensitive functions?
Are there functions or system calls which cannot permit an explicit century and whose format is governed by an industry standard or customer requirement?
Implicit century
Could the century in any date value in any date-sensitive function be misinterpreted for dates between 1985-01-01 and 2050-12-01?
Guidelines for Testing Century Compliance of a Compiler, Assembler,
or Interpreter
Compliance criterion
Guidelines for impact analysis
General integrity
Does language provide a function to obtain or set system date on the host or through a time service?
Does this function return the correct value for system date for high-risk dates:
1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29
Does this function return the correct value for system date after the system date rolls over on high-risk dates:
1998-12-31 -> 1999-01-01
1999-12-31 -> 2000-01-01
2000-02-28 -> 2000-02-29
2000-02-29 -> 2000-03-01
Date integrity
Does language support a data type for date values in the range 1900-01-01 to 2050-12-31?
Do the language routines treat 2000 as a leap year and 1900 as a non-leap year?
Does the date arithmetic correctly calculate differences between dates, add dates and durations, compute date of week?
Do the language routines correctly convert between date representations (YMD to Julian to base-and-offset )?
Does the language correctly compare dates?
Does language work with library of date routines? If so, does library perform correctly per questions in previous bullet?
Does system include sort/merge utility? If so, does sorting or merging on a date field produce correct sequence across dates in 19xx and 20xx?
Explicit century
Does date data type provide for explicit values for century?
Are there functions or system calls which cannot permit an explicit century, and whose format is governed by an industry standard or customer requirement?
Implicit century
Does date data type support formats without explicit century?
If value for century not explicitly set, what value is assumed in date comparisons, arithmetic, permanent storage, etc.?
Is century correctly inferred in all cases where century is not explicit.
Guidelines for Testing Century Compliance of a Database Management
System (DBMS)
Compliance criterion
Guidelines for impact analysis
General integrity
Does language provide a function to obtain the system date on the host or through a time service?
Does this function return the correct value for system date for high-risk dates:
1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29
Does this function return the correct value for system date after the system date rolls over on high-risk dates:
1998-12-31 -> 1999-01-01
1999-12-31 -> 2000-01-01
2000-02-28 -> 2000-02-29
2000-02-29 -> 2000-03-01
Date integrity
Does language support a data type for date values in the range 1900-01-01 to 2050-12-31?
Do the language routines treat 2000 as a leap year and 1900 as a non-leap year?
Does the date arithmetic correctly calculate differences between dates, add dates and durations, compute date of week?
Do the language routines correctly convert between date representations (YMD to Julian to base-and-offset internal)?
Does the language correctly compare dates?
Does a key index which includes a date field produce correct sequence across dates in 19xx and 20xx?
Does DBMS retrieve dates accurately for values in the range 1900-01-01 to 2050-12-31?
Explicit century
Does date data type permit setting explicit values for century?
Do retrieval functions permit formatting dates with explicit century?
Does DBMS retrieve date values accurately for values in the range 1900-01-01 to 2050-12-31?
Implicit century
Does date data type provide for data types without explicit century?
If value for century not explicitly set, what value is assumed in setting date field to a value, date comparisons, date arithmetic, etc.?
Guidelines for Testing Century Compliance of a Local-Area Network
(LAN)
Compliance criterion
Guidelines for impact analysis
General integrity
Does client network software obtain correct system date from the host for high-risk dates:
1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29
Does server network software obtain correct system date from the host for high-risk dates:
1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29
Does network-administration software obtain correct system date from the host for high-risk dates:
1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29
Does this function return the correct value for system date after the system date rolls over on high-risk dates:
1998-12-31 -> 1999-01-01
1999-12-31 -> 2000-01-01
2000-02-28 -> 2000-02-29
2000-02-29 -> 2000-03-01
Does LAN software accept and set time stamps correctly in the range 1985-01-01 to 2035-12-31?
Date integrity
Does admin software support expiration dates for user accounts, passwords?
Does calendar logic treat 2000 as a leap year and 1900 and a non-leap year?
Does the date arithmetic correctly calculate differences between dates, add dates and durations, compute date of week?
Do the language routines correctly convert between date representations (YMD to Julian to base-and-offset internal)?
Does the language correctly compare dates?
Do the network-admin software and API to network software accurately accept and retrieve all date fields in the range of values, 1900-01-01 to 2050-12-31?
Explicit century
Do time stamps provide for explicit values of century?
Does user interface in net administration software permit explicit entry and display of century in all date fields?
Does API to network software permit explicit entry and retrieval of century in all date fields?
Implicit century
For time stamps without explicit century, is a value for century inferred correctly for any manipulations of time stamps?
For date fields in user interface of admin software, which value for century is assumed if not entered?
For date fields in API, which value for century is assumed if application does not set it?
Guidelines for Testing Century Compliance
of a Custom Application
Compliance criterion
Guidelines for impact analysis
General integrity
Does language provide a function to obtain the system date on the host or through a time service?
Does this function return the correct value for system date for high-risk dates:
1999-09-09, 1999-12-31, 2000-01-01, 2000-02-29
Does this function return the correct value for system date after the system date rolls over on high-risk dates:
1998-12-31 -> 1999-01-01
1999-12-31 -> 2000-01-01
2000-02-28 -> 2000-02-29
2000-02-29 -> 2000-03-01
Are there third-party products embedded in this application? Are all these products century-compliant?
Does the application code ignore values for explicit century in the system date at any point in the program logic?
Date integrity
Does the programming language support a data type for date values in the range 1900-01-01 to 2050-12-31?
Does the application make a leap-year calculation? Do these calculations treat 2000 as a leap year and 1900 as a non-leap year?
Does the date arithmetic correctly calculate durations (differences) between dates, add dates and durations, compute date of week?
Does the application convert date values from one representation to another (for example, YMD to Julian to base-and-offset internal)? Does software correctly convert between date representations according to the Gregorian calendar?
Does the application compare dates in any of its branching logic or calculation of boolean values? Do all these comparisons produce correct results for all combinations of values with the expected ranges for dates?
Does the application include searching, sorting, merging, or indexing on internal tables, linked lists, or other data structures based on date variables? Do these operations perform correctly for all possible values for date in the key variables? Does a key index which includes a date field produce correct sequence across dates in 19xx and 20xx?
Does the application represent date in any variable as an offset from a base date/time? What is the maximum value for date for this representation? What is the minimum value for date for this representation (usually the base date)? Does the expected range of values for each variable using this date representation fall within these extremes?
Does the application use application assign values for date from one variable to another? Is the century portion of the value truncated during any assignment? Is the value in the target variable eventually used in a date manipulation which requires explicit century for correct results?
Does the application use language features which map a data address to more than one variable (such as REDEFINEs in COBOL or COMMON in FORTRAN)? In all aliases for the same data space, does any variable ignore or truncate a value for explicit century in the date value? Is the truncated value for date eventually used in a manipulation which assumes that all values for date share the same century?
Are constants for date values (including day, month, or year) used in any manipulation? Is the date constant intrinsic to the functional requirements or a special value used in a "date" data type for convenience?
Does the application store and retrieve dates accurately for values in the range 1900-01-01 to 2050-12-31?
Does the application use sort/merge utilities to order file contents on date fields or use indexed file structures keyed on date fields? Is this order correct for all values of date in the range 1900-01-01 to 2050-12-31?
Does the application rely on primary or alternate indices on a structured database for search, insert, update, or delete in which any key contains a date field? Will the index order be correct for all values for date in the range 1900-01-01 to 2050-12-31?
Are all date variables initialized to some convention for null value?
Guidelines for Testing Century Compliance
of a Custom Application (Concluded)
Explicit century
Does the application use a language, toolkit, and/or application generator which permits explicit century in the date data types? If so, are values for century in variables of these types supplied from external input or derived within the software logic?
Does the application use a DBMS or other layered (or horizontal) software product for data persistence to store and retrieve date variables? If so, can these products support explicit values for century in any date variable stored and retrieved?
Does the application have external interfaces (I/O, APIs, external subprogram calls, IPCs, library routines, HMI) which contains a date variable with explicit century? Does the software ignore, truncate, or write over the century value in any such variable as it flows through the program logic to any other external interface? In any such flow, could any logic alter the value for century in any manner inconsistent with generalized manipulations based on the Gregorian calendar?
Do all representations of date with explicit century both internal to the application and in all interfaces satisfy the criteria for century compliance?
Implicit century
Does the application use a language, toolkit, and/or application generator (including GUI builders) which permits date representation without an explicit century in the date data types? If so, is century derived for any manipulations or for passing a date value across any interface or for permanent storage? If so, is value for century correct for all values possible values of date each such variable can hold?
Does the application use constantvalues for date or portions of date (i.e., day, month, or year). If so, for any constant which is a full date value or value for year, is century not explicit in the value? Do all manipulations using each constant value directly or indirectly (that is, carried via variables to other operations in the program logic), produce the correct results for all possible values for such date variables?
Does the application use any application-program interface (API), such as in-line SQL or IMS DML, which passes date variables? If so, for any date value supplied across this interface, does the receiving software provide a default or derived value of century? Are the rules for derivation on both sides of the interface consistent with each other for possible values for date in the respective fields?
Does the application support a user interface containing date fields without explicit century? Is the century in each unambiguous to a user for all possible values for date in each such field?
Do all representations of date both internal to the application and in all interfaces satisfy the criteria for century compliance?
For further information directly related to Year 2000 issues, please contact Year2000@mitre.org
