
|
|
The INTERACTIVE(TM)
UNIX(R) System
and the Year 2000.
Sam Pierson and Blake Noah,
IUS Engineering,
Sun Microsystems Inc.
Version 1.3,
January 22nd, 1997.
1. Overview
The INTERACTIVE(TM) UNIX(R) System (IUS) supports a 32 bit internal
date representation, centered around the Epoch', January 1 00:00:00
1970, with a range from Dec 13, 1901 to January 19, 2038. This document
addresses the issues arising from the use of dates beyond the year 1999
and how IUS Engineering plans to address these issues with the upcoming
release of IUS, version 4.1.1, due to be released in 1997.
2. The y2000 Problem
Many legacy computer systems and programs have been written in a way
that fails to support dates after 1999. Generally, the problems fall into
two categories:
Ambiguous Usage
Many existing programs only accept or print two digits when entering
or displaying the year component of a date. Without known consistent guidelines
for interpretation, such representation becomes ambiguous when dates in
the range 1901-1938 or 2001-2038 are used.
Date Range Truncation
A few programs restrict the valid' date range in which they operate
to the twentieth century, forcing failure for twenty-first century dates.
3. Definition of y2000 Compliance
For the INTERACTIVE UNIX System, a program is deemed y2000 Compliant'
if it accurately and unambiguously accepts, stores, manipulates and displays
dates within the range 00:00:00 January 1 1970 to 03:14:07 January 19 2038,
as detailed in this document.
You will note that the date range specified above is a subset of the
possible date range that may be stored in a type time_t. This statement
is designed to fall in line with existing standards (IEEE 1003.1[1] and
XPG3[2]) and the draft recommendation on Millennium Rollover from X/Open[3].
For a statement on the use of dates before 00:00:00 January 1 1970 (negative
values of time_t), see Appendix I.
Note that this document does not address the extension of the maximum
representable date, 03:14:07 January 19 2038, inherent in the 32 bit time_t
data type. The INTERACTIVE UNIX System time_t type will remain a 32 bit
value. Customers with an immediate need for date manipulation beyond 2038
may wish to contact their sales representative and discuss migration to a version
of Solaris that uses a 64 bit time type.
4. y2000 Compliance Statement
Sun Microsystems Inc. ( Sun') will use reasonable efforts to make
the INTERACTIVE UNIX System y2000 Compliant' by the time its next version
is released, version 4.1.1, currently due to be shipped in 1997.
5. y2000 Compliance Policy
5.1 Unambiguous Display Interpretation
To be deemed y2000 Compliant' any use a of two-digit year must conform
to the following interpretation:
Values in the range 70-99 shall refer to the years 1970 to 1999.
Values in the range 00-38 shall refer to the years 2000 to 2038.
5.2 Full Date Range Support
Programs must not arbitrarily restrict date ranges to exclude twenty-first
century dates and must as a minimum accept dates within the range 1970-2038.
6. C Library Behavior
6.1 mktime(1P)
Many of the problems with routines in the C library are caused by the
same underlying bug in mktime():
Existing Behavior:
Incorrect: tm_year 00-01 maps to year range 2036-37.
Correct: fails (returns (time_t)-1 ) for tm_year 02-69.
Correct: returns correct time_t for tm_year range 70-137.
Incorrect: Fails for tm_year 138 (with all other fields 1).
Fail (return -1) for tm_year in range 00-69.
Accurately interpret tm_year 70-138. Note: this behavior conforms with
XPG3 within the limitations of the 32 bit time_t representation.
6.2 cftime(3C), ascftime(3C)
Reports incorrect year when using %y' specifier in conjunction with
year range 2000-2038, e.g.
- 2000 = :0
- 2010 = ;0
- 2020 = <0
- 2030 = =0
Planned Behavior:
Report two digit year correctly, i.e. does a correct year mod 100'
calculation.
6.3 ctime(3C), cftime(3C)
Prints years 2036, 2037 for years 1900 and 1901.
Planned Behavior:
This is due to the above described behavior in mktime and will be resolved
by that fix.
7. Command and Utility Program Behavior
7.1 date(1)
When used to set the time with format [mmddhhmmyy] with a yy' value
between 00 and 38, date will assume that these years are in the 20th century
and currently will resolve to 1970 due to a mktime() limitation.
Planned Behavior:
When used to set the time with format [mmddhhmmyy] with a yy' value
between 00 and 38, date will assume that these years are in the 21st century.
Existing behavior:
%y' specifier for date +format command prints out <char><n>
for years greater than 1999, where <char> is a member of the ASCII
character set above 9'.
Planned Behavior:
%y' will print 00' to 38' for years greater than 1999.
7.2 SCCS
The Source Code Control System (SCCS) embeds a date of the form yy/mm/dd
in an SCCS file when it is created or deltaed, e.g. Header for sccs file
create with system date set to 2010:
- ^Ad D 1.1 10/11/19 15:37:54 blake 1 0
- ^Ac date and time created 10/11/19 15:37:54 by blake
Planned Behavior:
As the format of SCCS history is an industry standard, we cannot unilaterally
change this format or fix this y2000 problem without consulting other vendors
and users of the SCCS program suite. As such, details of the fix for the
y2000 problem in SCCS were not available at the time of writing of this
document.
7.3 sccs: prs(1), get(1) -c cutoff' option
Specification of cutoff uses two digit year specifier with no century
indicator. Interprets years 00-38 as 1900-1938.
Planned Behavior:
Interpret 00-38 as 2000-2038.
7.4 passwd(1): -s option
For year range 2000-2038, incorrectly reports yy' element of mm/dd/yy
as 100-138
Planned Behavior:
Report yy' for 2000-2038 date range accurately.
7.5 lastlogin(1M)
Places incorrect date values in /usr/adm/acct/sum/loginlog. Reports
"00-00-00" for all users when year set to 2000-2038. Accurately
reports login date in form "YY-MM-DD" when used with pre-2000
dates, e.g.
- With system date in year 2010, reports: 00-00-00 blake
- With system date in year 1996, reports: 96-11-20 blake
Planned Behavior:
Report post-1999 dates correctly.
7.6 UUCP: uucico(1M), uustat(1M)
Displays 100-138 for years 2000-2038.
Planned Behavior:
Display 00-38 for year 2000-2038.
7.7 sar(1)
Displays 100-138 for years 2000-2038.
Planned Behavior:
Display 00-38 for year 2000-2038.
7.8 at(1)
With system date after year 2000, the at command refuses to accept any
job for scheduling. It returns error at: bad year.'
Planned Behavior:
Allow full job scheduling after year 2000.
7.9 acctcms(1M), acctcon1(1M), acctprc(1M)
Reports pnpsplit: invalid year: %d' when trying to operate on data
containing dates after 1999.
Planned Behavior:
Operate successfully with post 1999 data.
7.10 timex(1): -s option
Prints the date in range 100-138 when run with system dates with the
year in the range 2000-2038.
Planned Behavior:
Correctly print the year for 2000 and beyond.
7.11 lp(1)
The lp standard model interface program contains a hard-coded 19'
before the two digit year:
Printed: date '+%a %H:%M %h %d, 19%y'
Planned Behavior:
Routine will change to use %Y so that the correct four digit year is
reported.
8. Impact on Existing Customer and Third-party Applications
8.1 Third Party Application Program / Library Interaction
Statically linked applications that will be affected adversely by the
year 2000 rollover issues listed above must be recompiled (re-linked) with
Version 4.1.1 of the INTERACTIVE UNIX System to resolve the issues. Sun
bears no responsibility for such recompilation.
Programs Linked with the Shared C Library
Programs linked with the shared C library will automatically pick up
the changes make to address year 2000 rollover when run on Version 4.1.1
of the INTERACTIVE UNIX System and will not need recompiliation.
9. Disclaimer
While we have attempted to be exhaustive as possible in the compilation
of this document, it is possible that we have overlooked other components
of the system that may be adversely affected by the year 2000 roll-over.
If you can identify such a component, please contact your customer support
representative and ask them to file a bug report against this feature',
so that it may be brought to our attention. Moreover, while this paper
describes Sun's plans with respect to making the INTERACTIVE UNIX System
y2000 Compliant', Sun makes no representation or warranty that version
4.1.1 or any other version of INTERACTIVE UNIX in fact will be y2000 Compliant.'
Appendix I - Negative time_t.
POSIX (IEEE 1003.1) states that the result of using negative values
of time_t is undefined:
- 2.2.2.77 seconds since the Epoch: A value to be interpreted
as the number of seconds between a specified time and the Epoch.
- ...
- If the year < 1970 or the value is negative, the relationship
is undefined.[1]
The X/Open Portability Guide (XPG3) appears to disallow the use of negative
time_t. Negative time_t is used to report an error condition:
The mktime() function returns the specified time since the Epoch
encoded as a value of type time_t. If the time since the Epoch cannot be
represented, the function returns the value (time_t) -1.[2]
Other 2000AD proposals have explicitly ruled out the use of negative
time_t, by specifying the date range 1970 - 2038.
While this document details the behavior of dates between 1970 and 2038,
we are aware that negative values of time_t, i.e. dates before
1970, have been used and do work with some libraries and utilities.
For the purposes of y2000 compliance, the use of negative time_t
under the INTERACTIVE UNIX System is undefined. However, it is our intention
during development of y2000 support to allow use the widest range of time_t
possible for each function or program without causing ambiguity or unpredictable
behavior. As such users will find that negative time_t and dates
before the Epoch work with many library calls and utilities.
Appendix II - How we match other 2000AD recommendations
This document is partially consistent with the recommendations set forth
in draft version 0.6 of the X/Open white paper Year 2000: The Millennium
Rollover.':
Advice to implementors: Define %y such that values in the range
69-99 refer to the twentieth century and values in the range 00-68 refer
to the twenty-first century. [3]
We differ from this recommendation in that we cannot represent dates
after 2038 as the INTERACTIVE UNIX System time format will remain a signed
32 bit value.
Bibliography
[1] Portable Operating System Interface (POSIX) (IEEE
Std. 1003.1, ISO/IEC 9945-1)
[2] X/Open Portability Guide (XPG3)
[3] Year 2000: The Millennium Rollover' version 0.6
- from the X/Open Base Working Group
|