Solaris Products
How To Buy
Support Services


Solaris Site Map
  

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

    Planned Behavior:

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)

    Existing Behavior:

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)

    Existing Behavior:

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)

    Existing 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 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

    Existing Behavior:

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

    Existing behavior:

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

    Existing Behavior:

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)

    Existing Behavior:

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)

    Existing Behavior:

Displays 100-138 for years 2000-2038.

Planned Behavior:

Display 00-38 for year 2000-2038.

7.7 sar(1)

    Existing Behavior:

Displays 100-138 for years 2000-2038.

Planned Behavior:

Display 00-38 for year 2000-2038.

7.8 at(1)

    Existing Behavior:

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)

    Existing Behavior:

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

    Existing Behavior:

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)

    Existing Behavior:

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 Programs

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


Site MapWhat's Hot!FAQsSoftwareSales & Service
Questions or comments regarding this service? webmaster@sun.com

Copyright 1994-1997 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA. All rights reserved.