Compaq Computer Corporation
Year 2000 Readiness Tru64TM UNIX®
Year 2000 Readiness
© Digital Equipment Corporation 1997, 1998, 1999. All Rights Reserved.

This is a Year 2000 Readiness Disclosure of Compaq Computer Corporation.


Revision Information


Introduction

With the approach of the 21st century, there is concern about the ability of computer systems to provide accurate calculation and handling of date information beyond the year 2000 (Y2K). Compaq is well prepared to meet this challenge and to help its customers prepare for the next century. A thorough evaluation of Compaq's Tru64 UNIX (formerly DIGITAL UNIX) and the associated layered products has already been completed. Year 2000 enhancements and modifications became available with Version 4.0D of DIGITAL UNIX and will be maintained in all subsequent releases.

In addition to being the industry's only vendor that provides a complete and mature 64-bit computing environment, Compaq has added, with DIGITAL UNIX Version 4.0D and subsequent releases, warranted Year 2000 support and readiness. This "Year 2000 Ready" combination delivers to customers the advantage of a migration-proof product set well into the 21st century.

This document contains information about Compaq's Tru64 UNIX Year 2000 program and provides information that helps customers to prepare for the year 2000. The document highlights Y2K enhancements and modifications, includes important Y2K information on previous versions and layered products, and describes testing methodologies and guidelines.

Return to top of page


Background Information

In the past, it has been a common practice to represent dates in computer systems with only two digits for the year (for example, 96 instead of 1996). This practice was widespread from the 1960s to the 1980s to save space when the cost of disks and memory was relatively high. It was encouraged by many programming guides and some common specifications such as ANSI and DoD.

The use of only two digits to represent the year in dates causes the century to be ambiguous. Many programs assume the century to be the current 20th century. They interpret any 2-digit year to be in the range of 1900-1999, and they treat yy (a 2-digit year) as 19yy.

These kinds of programs can cause trouble as dates are projected beyond December 31, 1999, and when the current date reaches the year 2000 and beyond. For example, adding four years to 1997 in such a program would yield an erroneous date of 1901 instead of 2001.

Year 2000 problems can also occur where century information is available but lost by improper use of system date services during format conversions such as converting from binary to ASCII.

The following example illustrates the kinds of problems that are starting to occur now in some programs as the year 2000 approaches:

A company purchases new stock for its warehouse of a product manufactured in 1996 that has a 5-year shelf life. When the information is entered into the company's computer, the system determines that the product is 95 years out of date and promptly issues instructions to dispose of the new stock. This problem is caused by the application's use of 2-digit year data and an incorrect assumption about the century.

Return to top of page


Tru64 UNIX Year 2000 Readiness

Tru64 UNIX provides a robust date/time environment, and only minor changes were required for Year 2000 readiness. The system stores and tracks the current system time as the number of elapsed seconds since the standard UNIX Epoch date of 00:00:00 January 1, 1970 UTC. Application Programming Interfaces (APIs), such as the timeval struct and time_t data type, are used to retrieve system time into standard date/time-related data structures. Because the system stores time as an integral value, it is unaffected by a rollover of the century (see Time Handling on Tru64 UNIX).

Return to top of page


DIGITAL UNIX Version 4.0D and later

DIGITAL UNIX Version 4.0D has been available since January 19, 1998 and provides a Year 2000-ready environment for customers as they prepare for the turn of the century. All releases that ship after Version 4.0D are also Year 2000-ready.

DIGITAL UNIX Version 4.0D, including all system components and packaged layered products (see list in Compaq Layered Products), has gone through an extensive evaluation to ensure that dates are handled and represented properly for the year 2000 and beyond. Changes were made to ensure that Y2K support is consistent and robust throughout the system. All date APIs support 4-digit year input and output. Two-digit year support continues to be provided in order to be compatible with older applications. Two-digit year assumptions are consistent with The Open Group UNIX98 brand for Year 2000 date handling. The DIGITAL UNIX user documentation describes all Y2K enhancements.

All Y2K changes included in Version 4.0D are described in detail later in this document. (See Year 2000 Updates in DIGITAL UNIX Version 4.0D and Year 2000 Features Added in DIGITAL UNIX Version 4.0D.) Each DIGITAL UNIX and Tru64 UNIX release is tested with an extensive suite of functional, standards, and regression tests. Starting with DIGITAL UNIX Version 4.0D, Year 2000 regression tests, along with tests that run the full suite in a simulated Y2K system environment, have been added.

DIGITAL UNIX Version 4.0D, and later releases of DIGITAL UNIX and Tru64 UNIX, are warranted to be Year 2000 ready. You can obtain the specific Year 2000 warranty from your sales representative. (Also see DIGITAL Warranty Information.)

Several Y2K enhancements were provided after Version 4.0D shipped and are available in the current patch kit for Version 4.0D. These enhancements are also included in Version 4.0E and later. A description of the patches is provided later in this document to help determine if you need to install the patches. (See Year 2000 Patches for DIGITAL UNIX Version 4.0D.) Compaq recommends that customers have the latest patch kit installed on their Version 4.0D systems, but this is not mandatory for warranted Year 2000 readiness. Please contact your customer service center for information about obtaining and installing patch kits. Compaq world-wide contact information for DIGITAL products is available on Compaq's Web Site. (See Compaq World-wide Contact Information.)

Return to top of page


DIGITAL UNIX Versions 4.0B and 4.0C

In Versions 4.0B and 4.0C, the date command has been enhanced to allow setting the system date forward into the next century. This enhancement adds an optional century field for 4-digit year input (1970-2038 system date range). In addition, the date command now uses a sliding scale algorithm to interpret 2-digit year input (70-99 = 1970 to 1999, 00-38 = 2000 to 2038) so that entering 00 in the 2-digit year field sets the system date to the year 2000. These enhancements are consistent with The Open Group UNIX98 Year 2000 guidelines. This document contains further information on the standard 2-digit year handling algorithm.

This Y2K enhancement applies only to the date command. There are many other Y2K enhancements throughout the system that are proviced in Version 4.0D and later releases. You must be running Version 4.0D or later to have full Y2K support. The Year 2000 warranty applies only to Version 4.0D and later.

You should plan to upgrade to Version 4.0D or a later release in sufficient time to test your environment and to make necessary changes prior to the start of the year 2000.

Return to top of page


DIGITAL UNIX Version 4.0A and Earlier

The date command Year 2000 enhancement is available in the most recent patch kits for DIGITAL UNIX Versions 2.0, 3.0, 3.2A/B/C/D/E/F/G, 4.0, and 4.0A. Patch kits for these releases are available from the standard patch distribution for service customers. Please contact your customer service center for information about obtaining and installing patch kits.

This Y2K enhancement applies only to the date command. There are many other Y2K enhancements throughout the system that are provided in Version 4.0D and later releases. You must be running Version 4.0D or later to have full Y2K support. The Year 2000 warranty applies only to Version 4.0D and later.

You should plan to upgrade to Version 4.0D or a later release in sufficient time to test your environment and to make necessary changes prior to the start of the year 2000.

Return to top of page


Compaq Layered Products

This section provides information about products that are packaged with Tru64 UNIX and products sold in other ways.

Products Packaged with Tru64 UNIX

The following layered products are packaged with the Tru64 UNIX Media Kit and are available with DIGITAL UNIX Version 4.0D and subsequent releases. Each product has completed the same Year 2000 evaluation as the Tru64 UNIX operating system and includes any necessary modifications or enhancements. The specific versions of the products listed, and later versions, are warranted as Year 2000 ready.

Product Name Version
Logical Storage Manager 4.0D
Developer's Toolkit 4.0D
Polycenter AdvFS Utilities 4.0D
Prestoserve for DIGITAL UNIX 4.0D
TruCluster Available Server 1.5
TruCluster Production Server 1.5
TruCluster MEMORY CHANNEL Software 1.5
System V Environment 4.0D
Advanced Server for UNIX 4.0

Other Tru64 UNIX Layered Products from Compaq

Compaq's DIGITAL Year 2000 Program Office maintains a list of all Compaq layered software products and their Y2K status. This list is available on the Web at the following location:

http://ww1.digital.com/year2000/status.asp

Return to top of page


Methodologies and Guidelines for Testing Applications

The following strategies and recommendations are based on the procedures that were used to investigate and test Tru64 UNIX for Y2K issues. By sharing this information, Compaq hopes to provide some basic guidelines and a starting point for customers beginning their own Y2K efforts.

Strategies for Tackling the Year 2000 Problem

Taking Inventory

The first step in Y2K analysis is a complete and detailed inventory of all components that make up the product being tested. This might include high-level components such as applications and libraries. You can then break these components down into categories such as source code, data files, and so forth. You should keep track of any dependencies these components might have on other products or components, perhaps supplied by a third party. In particular, note any product or component that exchanges date or time information with the components being examined. An accurate inventory will provide scope for the investigation and can also serve as a checklist and basis for documenting what areas have been examined for Y2K problems.

Performing Code and Data Analysis

The next step involves filtering this initial inventory down to components that contain or reference any date and time-related code or information. This provides the necessary focus for performing more thorough analysis and testing. Performing this step requires knowledge of how date and time are used in each component. You can use the y2ksniff tool to detect many common areas of date and time usage in source code and modules. However, only a careful analysis of date and time usage will uncover all areas needing to be examined. For example, an application might use a custom data type named counter to keep track of time in some manner. This might not be immediately apparent without thorough examination of the code.

You must analyze how date and time is used in each component, particularly in the areas of arithmetic operations, comparisons, sorting, expiration or out-of-bounds values, and 2-digit year handling. Some of the more common time-related data types, routines, and commands that Tru64 UNIX uses are listed in a later section. Using some level of automation in the analysis stage (such as the y2ksniff tool) can be helpful, but only a thorough and direct examination of each component will uncover all potential Y2K problems. Some examples of potential problems and fixes are also provided in the section titled Examples of Year 2000 Problems and Solutions. Do not view this as a cookbook, as specific problem areas will vary greatly from one component or application to another.

Once you have analyzed the code and data and addressed all known Y2K bugs, you can begin testing the components.

Testing

Testing for Y2K problems involves first identifying specific components or areas to target for testing. You should develop a test plan that includes each of these areas and describes what methods will be used to test them. Important questions to ask are:

  • What specific procedures must be followed to allow testing in a Y2K environment (see Testing Guidelines)?

  • What scenarios are likely to uncover problematic areas?

  • Can the tests be automated?

  • Is the source code available for the components being tested?

  • What dates or date ranges should be used for testing?

Once you establish a detailed test plan, you can begin testing. When setting the system date forward for testing on Tru64 UNIX, be sure to follow the Testing Guidelines to avoid any unexpected problems.

Implementing Fixes and Workarounds

Addressing Y2K problems that have been identified might be as easy as changing a line of code and recompiling an application. However, it might also be very complex and involve rewriting entire modules or applications with new implementations. Fixes and workarounds are certainly much easier to implement if the source code is available. However, this is not always the case and you might need to consider other alternatives. See Examples of Year 2000 Problems and Solutions.

Documenting Findings

Keeping accurate records of components analyzed and tested for Y2K provides assurance that all areas have been covered. Listing the specific bugs or issues found along with their associated fixes or workarounds can also provide the groundwork for other Y2K efforts. These will also likely be important issues to consider when developing or integrating new code.

Return to top of page

Time Handling on Tru64 UNIX

Tru64 UNIX uses standard date/time data structures and APIs to store, track, calculate, interpret, convert, and represent time. Application developers must have a proper understanding of these interfaces in order to use them correctly and to avoid potential Y2K problems in their code. A list of common Tru64 UNIX date/time data structures and APIs, and explanations of how time is used in Tru64 UNIX, follows.

Common time-related data structures that Tru64 UNIX uses

  • time_t

    An opaque data type used to store the number of seconds since the standard UNIX Epoch, 00:00:00 January 1, 1970 UTC.

  • struct  tm {
            int     tm_sec;         /* seconds after the minute [0-60] */
            int     tm_min;         /* minutes after the hour [0-59] */
            int     tm_hour;        /* hours since midnight [0-23] */
            int     tm_mday;        /* day of the month [1-31] */
            int     tm_mon;         /* months since January [0-11] */
            int     tm_year;        /* years since 1900 */
            int     tm_wday;        /* days since Sunday [0-6] */
            int     tm_yday;        /* days since January 1 [0-365] */
            int     tm_isdst;       /* Daylight Savings Time flag */
            long    tm_gmtoff;      /* offset in seconds from GMT (UTC) */
            char    *tm_zone;       /* Time zone string, for example "GMT" */
    };
    

    A structure used to store time broken down into its various components as previously listed.

  • struct timeval {
            time_t  tv_sec;         /* seconds */
            int     tv_usec;        /* microseconds */
    };
    

    A structure that contains time expressed as a time_t data type (described earlier) as well as a microseconds (tm_usec) field to provide finer granularity. This structure is used to store, get, and set time in the kernel.

Routines that retrieve the time of day from the kernel

  • time()

    Returns the current time as a time_t data type (seconds granularity).

  • gettimeofday()

    Retrieves the current time and stores it in a timeval struct (microseconds granularity).

Routines that set the time of day in the kernel

  • stime()

    Sets the system time based on the number of seconds since the standard UNIX Epoch, 00:00:00 January 1, 1970 UTC (seconds granularity).

  • ftime()
    settimeofday()

    Sets the system time based on the number of seconds since the standard UNIX Epoch, 00:00:00 January 1, 1970 UTC as well as the number of microseconds (microseconds granularity).

Routines that convert time to ASCII representations

  • strftime()

    Fills in a character array based on input from a tm struct and a set of format specifiers.

  • ctime()

    Returns a pointer to a character array that contains a preformatted time representation based on input of a time_t data type.

  • asctime()

    Returns a pointer to a character array that contains a preformatted time representation based on input of a tm struct.

Routines that convert time from ASCII representations to binary

  • strptime()

    Fills in a tm struct with values based on character array input that is interpreted using various format specifiers.

  • getdate()

    Returns a pointer to a tm struct based on character array input that is interpreted using format specifiers stored in a text file indicated by the DATEMSK environment variable.

Routines that convert between time data types

  • localtime()

    Converts a time_t data type into a tm struct with values based on time zone information on the system or as specified by values stored in the tm struct.

  • gmtime()

    Converts a time_t data type into a tm struct with values based on Coordinated Universal Time (UTC), also referred to as GMT.

  • mktime()

    Converts a tm struct into a time_t data type and performs normalization (or adjustments) based on the time zone and other values stored in the tm struct.

The date command

Displays the time and date based on default or user-specified formats. Also used to set the system time and date.

Network time handling

Network Time Protocol (NTP) -- System time is set by polling a specified server if NTP is configured.

Overview of time usage in Tru64 UNIX

  • The user is queried for time during installation.

  • The time is stored in a timeval structure in the kernel (system time).

  • The system time is updated regularly, based on hardware clock ticks.

  • The system time can also be updated by:

    • API calls such as stime(), ftime(), or settimeofday()

    • The date command

    • NTP polling

  • Applications can query system time by using APIs such as time() or gettimeofday().

  • Applications can convert between time data types by using APIs such as localtime(), gmtime(), or mktime().

  • Applications can convert to ASCII representations by using APIs such as strftime(), ctime(), or asctime().

  • Time can be displayed by using commands such as the date command.

Return to top of page


Testing Guidelines

Tru64 UNIX allows the clocks of its systems to be set to times in the future so that customers can test their software for potential Year 2000 issues. Enhancements have been made to the Tru64 UNIX date command to support setting the system date past the year 1999. These enhancement are included in DIGITAL UNIX Version 4.0B and later releases. Customers running previous versions of DIGITAL UNIX (or DEC OSF/1) as far back as Version 2.0 can also obtain the enhanced date command for their systems by installing the most recent patch kit for their system. See DIGITAL UNIX Version 4.0A and Earlier for information on the enhanced date command and patch kits.

It is important follow the guidelines outlined in this section carefully to avoid unexpected problems and ensure that your tests run smoothly.

Warning Take Precautions!

To ensure data integrity during these test sessions, use the following precautions. These precautions are similar to those associated with other common maintenance operations, such as system upgrades.

  • To avoid timeout problems when setting the system date forward for testing, make sure the system contains permanent license Product Authorization Keys (PAKs) without expiration dates.

    Do I have PAKs that are going to expire?

    The software license PAKs in field test versions of Tru64 UNIX and final versions shipped to certain ISVs and educational institutions include expiration dates. To allow these customers to conduct Y2K testing, a test PAK for Tru64 UNIX and DIGITAL UNIX, 00Y2K-TESTING, is available from Compaq beginning with DIGITAL UNIX Version 4.0D. Customers with expiring license PAKs can install the test PAK, allowing their PAKs to operate between the dates of December 1, 1999 and March 2, 2000. Customers using the 00Y2K-TESTING test PAK should read Special Procedures for Expiring PAKs for important Y2K testing information.

    For information about PAK expiration dates and installation, see the Tru64 UNIX and the reference page. If you are not sure whether your system should have permanent license PAKs, contact your local representative.

    How do I obtain the Tru64 UNIX Year 2000 Test PAK?

    Information is available from the program office responsible for issuing your "date limited" PAK(s):

    CSLG Program http://www.digital.com/info/education/
    Compaq Solutions Alliance Program http://www.compaq.com/csa/
    Partner PAK Program Send mail to pakman@groove.zko.dec.com

    PAKs issued by Independent Software Vendors (ISV) who use Compaq's License Management Facility (LMF) might have date limitations. Licensees should contact their software vendor if it is necessary to perform Year 2000 testing.

  • If you are running a version of DIGITAL UNIX prior to Version 4.0B, contact your local representative to obtain and install the enhanced date command on the system under test. The 00Y2K-TESTING features work only with DIGITAL UNIX Version 4.0D and subsequent releases.

  • To avoid complications with other networked systems, the systems under test must not be part of a production environment at the time of testing. Compaq recommends that you disconnect machines under test from any local area network. If you cannot do this, then you should terminate network time daemons or commands such as xntpd (NTP daemon), timed, or rdate on the test machines. Interaction between systems with the date set forward (for Y2K testing) and other machines using the current date can lead to time anomalies on all systems connected to a network, the most obvious being the propagation of future time to systems expecting current time and vice versa. The outcome of such interaction can result in serious problems (even crashes) on systems not intended or properly configured for use in a Y2K testing environment. This need for test system isolation becomes even more critical in networks comprising systems from multiple vendors because the behavior of such heterogeneous environments cannot be predicted.

Compaq recommends the following procedure for setting the date forward:

  1. Stop pending or suspended processes.

  2. Shut the system down and reboot it.

  3. Perform a complete backup of the system's disks to ensure that the original data can be restored after testing.

Moving the System Date Forward

You can use the enhanced date command to set the system date forward. It is important that you set the system date in single-user mode only. Changing the date in multiuser mode could cause the creation and modification dates for user files to be inconsistent. When moving the system date to times in the future, the system disk must be updated with the new year information. After moving the date forward in single-user mode, enter the following command:

mount -u /

This will write the new year into the superblock on the system disk and cause the root file system to be mounted read/write. See the reference page for further details on setting the system date.

Once the time has been set forward properly, you can perform tests. Refer to Recommended Test Dates and Examples of Year 2000 Problems and Solutions for tips on testing strategies.

Special Procedures for Expiring PAKs

Customers running DIGITAL UNIX Version 4.0D or later who have expiring software license PAKs must observe the following guidelines once they have installed the 00Y2K-TESTING PAK for testing:

  1. Once the 00Y2K-TESTING PAK is installed and the system date is set forward in single-user mode for Y2K testing, execute the following command from the root account the first time run level 3 (also referred to as "init 3" or "multiuser mode") is entered after each system boot:

    /usr/sbin/lmf reset

    This command ensures that all software licenses are loaded while the system date is set within the Y2K testing window. You can execute execute this command repeatedly, but only one execution is required for each system boot. That single required execution must occur while the system is at run level 3.

  2. After executing the command, you can toggle the system between run level 1 and run level 3 without executing the command again. Only subsequent system boots require the command to be executed again.

Restoring the System to its Original State

When testing is complete, the system can be restored to the present date:

  1. Stop any pending or suspended processes left by the advanced date testing.

  2. Shut down and reboot the system.

  3. After all the tests have been performed and the system shutdown and reboot are completed, reset the system date to the current date and time by using the date command, NTP, or any other method you prefer.

  4. Restore the disk backups so that normal production operation can resume.

Recommended Test Dates

The following are some recommended dates for use in Y2K testing:

  • Beginning of year

    Although January 1, 2000 is the most notable date to test against, it is also a good idea to test other year transitions as well to confirm that no annual problems unrelated to Y2K exist.

    January 1, 1999
    January 1, 2000
    January 1, 2001

  • End of year

    End-of-year dates are good starting points to test transitions into the following year.

    December 31, 1998
    December 31, 1999
    December 31, 2000

  • Leap year

    Despite some confusion over this issue, the year 2000 is indeed a leap year. The following flow chart shows how leap years are determined:

    Yeap Year flowchart

    This is why the year 1800, though evenly divisible by 4, was not a leap year, but the year 2000 will be.

    February 28, 2000 (to begin transition to February 29, 2000)
    February 29, 2000 (to confirm leap year is recognized)
    March 1, 2000 (to confirm transition from February 29, 2000)

  • Possible "out-of-bounds" dates (dates that application developers might have considered unreachable and therefore used to determine valid or invalid dates)

    September 9, 1999 (corresponds to 9/9/99)
    September 10, 1999 (to confirm transition from 9/9/99)

During the testing, it might be useful to set the system date to some fixed time before the intended testing date in order to observe behavior while the transition is taking place. An appropriate buffer such as this might also provide necessary time to move an application into a desired state before the relevant time transition takes place. Keep in mind that these are only recommendations and that more thorough testing might be required to test certain applications sufficiently.

Return to top of page


Common Ways to Address Year 2000 Issues

Always use the full four digits to represent the year where possible. If you must use a 2-digit year (for compatibility reasons, for example), implement an appropriate algorithm for interpreting the two digits to determine the intended century. Tru64 UNIX uses the following standard algorithm for handling 2-digit years:

If the year is between 69 and 99, the 20th century is assumed (19yy).

If the year is between 00 and 68, the 21st century is assumed (20yy).

This algorithm is consistent with the current UNIX98 specification from The Open Group. It is based on the fact that time on UNIX systems is stored as a number of seconds since the standard UNIX Epoch (00:00:00 January 01, 1970 UTC) and provides a one-year variance to account for local times in different time zones. For example, at 00:00:00 January 01, 1970 UTC, the local time in Eastern Standard Time (EST) was 19:00:00 December 31, 1969 EST. Note that many system interfaces on Tru64 UNIX use the standard data type, time_t, which restricts the upper limit of the previous algorithm to the year 2038. Because of this, 2-digit years between 38 and 68 might be rejected by certain interfaces. See UNIX 2038 Time Limit for more information on this issue.

Consistently use standard system APIs for handling date/time data calculations. You can use routines such as mktime(), localtime(), strftime(), strptime(), getdate(), ctime(), difftime(), time(), and others to perform most date/time manipulations and representations. Consistent use of these routines helps to avoid problems that can arise with nonstandard interfaces. Use of standard routines also enables the development of more portable code.

The tm_year field of the tm struct is a common area for arithmetic omissions or mistakes. The tm_year field is defined as the number of years since 1900 (for example, for the year 1999 tm_year = 99). Since tm_year values in the 20th century do not exceed two digits (0-99), many applications have assumed this is an appropriate means of representing years as a 2-digit value and simply output or store this value for the year. This is a mistake. When the year 2000 arrives, tm_year values will exceed two digits (that is, for the year 2000, tm_year = 100).

Consistent use of 4-digit years employing a simple calculation such as tm_year + 1900 avoids misinterpretations. If a 2-digit year is required, you must use appropriate arithmetic on the tm_year value. For example, for years beyond 1900 the calculation tm_year % 100 provides the correct 2-digit year regardless of the century.

Return to top of page


Examples of Year 2000 Problems and Solutions

The following examples are by no means a complete list of Year 2000-related issues developers might expect to find in their code. Applications can use an endless variety of ways to input, process, calculate, and output time and date information, resulting in many different kinds of Y2K problems. These examples simply provide an introduction to the kinds of problems developers should be looking for.

  • tm_year field in tm struct (years since 1900)

    Application code might display two digits for the year by simply displaying tm_year. This yields correct 2-digit representations until the year 2000, at which point the number of years since 1900 becomes a 3-digit number.

    Correct usage: Use full 4-digit years instead (tm_year + 1900). If a 2-digit year is absolutely required, use tm_year % 100, which yields the correct 2-digit year regardless of the century. Remember that century information is lost by using 2-digit years and can result in additional problems or century ambiguity, depending on how this data is used.

  • Hard-wiring of century (19) in application code

    Code might hard-wire the century as in:

    printf("year = 19%d\n", tm_year);

    This can yield correct results for years in the 20th century (1997, 1998, 1999). However, when the year 2000 arrives, this method will yield incorrect results (19100, 19101, 19102, ...).

    Correct Usage: Use 4-digit years, as in:

    printf("year = %d\n", tm_year + 1900);

  • Ambiguous 2-digit year input using API getdate()

    The getdate() routine is defined as follows:

    struct tm *getdate(const char *string);

    Data input through string is parsed according to format specifiers stored in a text file referenced by the DATEMSK environment variable (see the reference page for more details).

    The %y format specifier is defined as "Year of century 00 through 99" and is a 2-digit value. If this format specifier is used, as in %m/%d/%y (month/day/year), it can be unclear what century was intended by the input data. For example, the file referenced by DATEMSK contains the following format:

    %m/%d/%y

    Application code retrieves input (perhaps from a user interface) of the form 11/22/02 and calls getdate() as follows:

    struct tm * p_tm;
    p_tm = getdate( "11/22/02" );

    Because the century is not required or specified, it is unclear whether the input is intended to refer to 11/22/1902 or 11/22/2002. In DIGITAL UNIX Version 4.0D and later, the getdate() routine interprets this 2-digit year input according to the standard 2-digit year handling algorithm. However, this might not be consistent with the intended meaning of "02" in the input.

    Correct usage: Use the %Y field specifier instead of %y to require and to specify full 4-digit year input. For example, modify the previous format as follows:

    %m/%d/%Y

    Require 4-digit year input and process as follows:

    struct tm * p_tm;
    p_tm = getdate( "11/22/2002" );

    This leaves no ambiguity as to the intended century.

Return to top of page


Year 2000 Updates in DIGITAL UNIX Version 4.0D

DIGITAL UNIX Version 4.0D addresses the following Y2K issues:

  • /usr/bin/date, /sbin/date

    Enhanced the date command (/usr/bin/date, /sbin/date) to allow setting the system date beyond the year 2000. Added a 4-digit input field for specifying the year. In addition, implemented an algorithm for interpreting input from the existing 2-digit year field. See DIGITAL UNIX Versions 4.0B and 4.0C and Common Ways to Address Year 2000 Issues for more details on the standard 2-digit year handling algorithm. Also, implemented an algorithm for interpreting input from the existing 2-digit year field (69-99 = 19yy, 00-68 = 20yy). These changes are consistent with the most recent changes and additions to the UNIX98 specification from The Open Group. The date command also identifies ambiguous date setting input (input that could match more than one date input format) and indicates the default format to be used. See the reference page for more details.

  • /usr/bin/admin, /usr/bin/get, /usr/bin/delta, /usr/bin/prs (SCCS commands)

    Updated the SCCS commands to employ the standard 2-digit year handling algorithm for options that accept 2-digit year input. In addition, modified the prs command to correctly display 2-digit years where appropriate, using appropriate arithmetic on the tm_year member of a tm struct (tm_year % 100).

  • /usr/bin/touch

    Updated the touch command to employ the standard 2-digit year handling algorithm for options that accept 2-digit year input.

  • /usr/bin/at

    The at command contained a check against a maximum tm_year value of 100, thereby rejecting the year 2000 and beyond. The code was adjusted to accept all valid years since the standard UNIX Epoch.

  • /usr/sbin/setld

    Removed the hard-wired century "19" from two format strings used to query the current date/time from the date command for logging purposes. The %Y format specifier is now used to retrieve the correct 4-digit year.

  • Configuration phase of full installation

    Modified the date input prompt to inform the user that a 4-digit year is allowed. Updated syntax used to invoke the date command to allow both 2-digit and 4-digit input, since the date command can now accept either.

  • Graphical and character-cell full install interfaces

    Added more robust range checking for date input and associated warning messages. These ranges include out-of-range month, day, and year numbers, including false leap years.

  • Various system-accounting utilities

    Removed the hard-wired limitation on years past 2000 in the library used to build various system accounting utilities.

  • /usr/bin/X11/dxpaint

    Replaced the hard-wired century "19" with the correct full 4-digit year value in code that writes the creation date into the CreationDate field in thePostScript output. The original code assumed the tm_year field to be a 2-digit value.

  • /usr/bin/X11/dxprint

    Replaced the hard-wired century "19" with the correct full 4-digit year value in code that writes the creation date into the CreationDate field in the PostScript output. The original code assumed the tm_year field to be a 2-digit value.

  • /usr/sbin/audit_tool

    Corrected the calculation of ASCII values based on the tm_year field. This allows audit_tool to correctly select audit events by date for events that occur after the year 2000.

  • Various MH mail utilities

    Corrected several hard-wired century "19" assumptions in the MH mail package. The original code assumed the tm_year field to be a 2-digit value. Also corrected 2-digit year output to use full 4-digit years instead.

  • /usr/bin/X11/dxaccounts, /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/userdel, /usr/sbin/groupadd, /usr/sbin/groupmod, /usr/sbin/groupdel

    Expanded the command line options for dxaccounts and related tools to accept 4-digit year input in addition to existing 2-digit year input. The standard 2-digit year handling algorithm was employed for 2-digit year input.

  • strptime() (standard C library)

    Updated strptime() to implement the standard 2-digit year handling algorithm for the %y (year within century) and related specifiers. Also added the %C (century number) specifier. These are consistent with the current UNIX98 specification from The Open Group. Added code to enforce 4-digit input for the %Y (year including century) specifier so that other input such as 2-digit data is not erroneously accepted.

  • getdate() (standard C library)

    Updated getdate() to implement the standard 2-digit year handling algorithm for the %y (year within century) and related specifiers. Also added the %C (century number) specifier. These are consistent with the current UNIX98 specification from The Open Group. The %Y (year including century) specifier remains correct for full 4-digit year input.

  • /usr/bin/X11/dxcalendar

    Modified dxcalendar to expand the accepted date range when importing calendar data beyond the year 1999. Previously, dxcalendar imposed a limit of 100 on year tokens directly derived from the tm_year element (years since 1900) in the standard UNIX tm struct, thus limiting input to the year 2000. Also corrected to handle 2-digit years correctly using the standard 2-digit year handling algorithm.

  • /usr/bin/date, /usr/sbin/whodo, /usr/bin/cb (SVE versions)

    Changed several SVE (System V Environment) commands. Enhanced the date command to ensure proper handling of 2-digit years. Updated the whodo command to display a 4-digit year for login dates older than 18 days. Modified the cb command to allow the -V option to display a 4-digit year in the range 1970 to 2038.

  • /usr/lib/libpset.a, /usr/shlib/libpset.so, /usr/sbin/pset_info, /usr/sbin/psrinfo

    Modified the wtmp_search() routine in libpset to report dates that use 4-digit years instead of 2-digit years, applying correct arithmetic on the tm_year field of a tm struct (tm_year + 1900). The pset_info and psrinfo commands both call this routine and now report dates that use full 4-digit years.

  • /usr/sbin/ftpd

    Replaced the hard-wired century "19" with the correct full 4-digit year value in the ftpd MDTM subcommand. The original code assumed the tm_year field to be a 2-digit value and simply appended the century "19" to this value when converting the date for display. This problem and fix may be observed as follows on a file with a modification time beyond the year 2000:

    ftp> modtime /2001.file
    /2001.file      10/10/1910 12:00:44 GMT
    
    ftp> quote mdtm /2001.file
    213 191010101200442
    

    Using the fixed version of ftpd, the same tests yield the following correct results:

    FTP> modtime /2001.file
    /2001.file      01/01/2001 20:04:42 GMT
    
    ftp> quote mdtm /2001.file
    213 20010101200442
    

    This issue affects only the display of the file modification time. The underlying file is not affected by these commands.

  • /usr/sbin/tcpdump

    Modified tcpdump to display the correct 4-digit years in time output. The original code assumed that the tm_year field of a tm struct was an appropriate 2-digit year representation. This problem and fix may be observed as follows:

    Original Format:

    tcpdump.log 97y06m30d15h17m57s450976u 97y06m30d15h18m05s202746u
    tcpdump.log 101y06m30d15h17m57s450976u 101y06m30d15h18m05s202746u
    

    New Format:

    tcpdump.log 1997y06m30d15h17m57s450976u 1997y06m30d15h18m05s202746u
    tcpdump.log 2001y06m30d15h17m57s450976u 2001y06m30d15h18m05s202746u
    

  • /usr/sbin/jdbdump

    Modified the get_date() routine in the dhcp (Dynamic Host Configuration Protocol) utility library to understand years greater than 1999. This problem and fix may be observed as follows:

    # jdbdump -a -s 1/1/2000
    (null) is not in any recognized date-time format
    Usage: jdbdump [-f ] [-t] [ ....]
    
    # jdbdump.new -a -s 1/1/2000
    08:00:2b:2c:ec:bc|1|6|16.142.160.57|Sat Jan  1 02:17:42 *2000*|
    Sat Jan  1 02:18:42 *2000*|Sat Jan  1 02:18:12 2000|Sat Jan  1
    02:17:42 2000|16.142.160.55|||
    

  • /usr/bin/dtifddif (CDA DTIF to DDIF converter)

    Replaced the hard-wired century "19" with the correct full 4-digit year value in code that writes the creation date.

  • /usr/lbin/udetect, /usr/lbin/invcutter, /usr/lbin/fverify

    Modified these commands to use appropriate arithmetic on the tm_year member of a tm struct (tm_year % 100) to display correct 2-digit years in date output.

  • /usr/bin/ltf

    Modified the display to use correct 2-digit years based on the tm_year member of the tm struct (tm_year % 100). Also corrected the 4-digit year representation for years after 2000 (tm_year + 1900).

  • /usr/sbin/sendmail

    Modified sendmail to use correct arithmetic on the tm_year member of a tm struct (tm_year + 1900) to display correct 4-digit years in header fields that contain the date.

  • CDE subsystem

    Corrected arithmetic in two minor areas that use the tm_year member of a tm struct to display correct 2-digit years (tm_year % 100) and 4-digit years (tm_year + 1900).

  • /usr/dt/share/examples/dtdnd/*.c (Drag-n-Drop Demo source)

    Modified the Drag-n-Drop Demo source files buff.c and dtdnddemo.c to display 2-digit years that use correct arithmetic on the tm_year member of a tm struct (tm_year % 100).

  • /usr/bin/X11/xterm

    Modified the source code to use correct arithmetic on the tm_year member of a tm struct (tm_year % 100) to show the correct 2-digit years when displaying the date.

Return to top of page


Year 2000 Patches for DIGITAL UNIX Version 4.0D

The following Y2K enhancements were provided after DIGITAL UNIX Version 4.0D shipped and are available in the current patch kit for Version 4.0D. These enhancements are also included in Version 4.0E and later.

  • /usr/bin/at

    The /usr/bin/at command was not properly handling the date, February 29, 2000 (leap year 2000). Jobs specified for this date would erroneously be scheduled for March 1, 2000 instead. This problem has been fixed and is available in the latest DIGITAL UNIX Version 4.0D patch kit.

  • strftime() (standard C library)

    The strftime() function was displaying incorrect values for the %y (year within century) format specifier only when width and/or precision modifiers were used (ie: %02.02y) and the year specified was greater than 1999. This has been corrected. Use of the %y specifier without width and/or precision modifiers remains correct and this is the standard usage. The width and precision modifiers are Compaq extensions and not part of the UNIX standard. This fix is available in the latest DIGITAL UNIX Version 4.0D patch kit.

Return to top of page


Year 2000 Features Added in DIGITAL UNIX Version 4.0D

The following Y2K features have been added to DIGITAL UNIX Version 4.0D:

  • /usr/sbin/lmf, /usr/sbin/lmfck, kernel

    Enhanced the lmf utility and supporting code to allow customers with expiring software license PAKs to set the system date beyond the expiration dates within a specific time window to allow Y2K testing. See the 00Y2K-TESTING test PAK information and Special Procedures for Expiring PAKs for more information on these features.

  • /usr/bin/y2ksniff

    Developed an analysis tool, y2ksniff, to aid in Y2K investigations. This tool allows you to search for common areas of date and time usage in source code, shell scripts, object files, executables, data files, and others. Its features include a customizable search list, record viewing and editing cycle, and customizable instrumentation routines for run-time analysis of executables with or without source code. The y2ksniff tool and associated source code are free of charge via Compaq's Tru64 UNIX Year 2000 World Wide Web page. Compaq encourages you to take advantage of this tool, and welcomes feedback and suggestions for future enhancements.

Return to top of page


General Time-Related Updates in DIGITAL UNIX Version 4.0D

The following changes are not Y2K specific but are related to time handling on Tru64 UNIX and might be of interest to those working on Y2K issues.

  • /usr/ccs/lib/librt.a, /usr/shlib/librt.so

    Modified the clock_settime() RTL routine in librt to correctly check the nanoseconds field instead of the seconds field of a timespec struct for values greater than 1000000000. The incorrect check against the seconds field resulted in a date-setting limitation of 19:46:39 September 8, 2001. Attempts to set times beyond this date resulted in an EINVAL error. This problem has been corrected.

  • Kernel, standard C library

    Fixed the setitimer() routine to avoid problems when changing time backward or forward while in multiuser mode. Previously, the setitimer() routine could hang the system for a long time or set a timer to expire far into the future if the system time was changed forward or backward significantly. Although this fix is not Y2K specific, it does aid in avoiding system hangs when moving the system time back and forth during Y2K testing.

  • Installation setup

    Fixed the problem that caused the screen to go blank when the user set the time in the installation setup. The cause of this problem was the screen saver, which kicked in if the time was set ahead of the current time by more than the screen saver timout period. Option -s 0 was added to X server startup to disable the screen saver. Although this fix is not Y2K specific, it does avoid problems that would occur when performing Y2K testing.

  • CDE_CM dtcm CompareCalendars

    Added bounds checking for valid years in CompareCalendars. Previously, CompareCalendars would allow toggling of years beyond 2037 and eventually overflow the limits of a time_t, causing a wrap back to 1970.

  • /usr/bin/at

    The at command was updated to reject time parameters that contained more than four digits. This is separate from date parameters. Also, if the colon separator (between the hours and minutes) is misplaced in the time expression, the time is rejected.

  • /usr/shlib/libc.so, /shlib/libc.so, /usr/ccs/lib/libc.a, /usr/lib/libc.a

    The mktime() function in libc did not provide a way to distinguish between an error value and a valid time_t return corresponding to 23:59:59 December 31, 1969 UTC (1 second before the standard UNIX Epoch). Various standards, including UNIX98, specify that mktime() return a time_t data type and use a return value of (time_t)-1 to indicate that the time specified by the tm struct argument was not representable. However, at 1 second before the Epoch, the valid return value of mktime() is also (time_t)-1. The standards currently provide no way to distinguish between these two conditions. The mktime() function on DIGITAL UNIX and Tru64 UNIX has been enhanced to additionally set errno to the value ERANGE in the event that the time is not representable. Callers of mktime() can now check both the return value and the value of errno to reliably determine if an error has occurred. Note that this extension is not a standard feature and might not be portable to other UNIX platforms.

    Also, mktime() has been enhanced to provide more accurate bounds checking, properly rejecting time values that exceed the size limitations of the return type, time_t.

  • /usr/tcb/bin/edauth

    Modified the edauth command to interpret 2-digit year input correctly, using the standard 2-digit year handling algorithm.

Return to top of page


Related Web Pages

Compaq Computer Corporation http://www.compaq.com/
Digital Equipment Corporation
(now part of Compaq Computer Corporation)
http://www.digital.com/
Compaq's DIGITAL Year 2000 Program Office http://www.digital.com/year2000/
Compaq's Tru64 UNIX Home Page http://www.unix.digital.com/
Compaq's Tru64 UNIX Year 2000 Home Page http://www.unix.digital.com/unix/year2000/
Latest Copy of This Article http://www.unix.digital.com/unix/year2000/whitepaper.html

Return to top of page


Related Issues

Hardware All Compaq and DIGITAL Alpha hardware systems are Year 2000 compliant now and do not require any changes or modifications.
UNIX 2038 Time Limit The 2038 time limit stems from the industry-wide use of a 32 bit signed data type (such as time_t as described above) to store the number of seconds since the standard UNIX Epoch. This data type has the following corresponding time limitations:

  • Lower limit: 20:45:52 December 13, 1901 UTC
  • Upper limit: 03:14:07 January 19, 2038 UTC

The Year 2000 program for Tru64 UNIX does not address this standard UNIX time limitation. This is a general UNIX issue that standards organizations and vendors are starting to address. Compaq is actively involved with this effort and will provide a timely solution consistent with industry standards. As more information about this issue becomes available, Compaq's Tru64 UNIX Year 2000 Information site on the World Wide Web will provide up-to-date references.

Return to top of page


Revision Information

Revision Date Description
1.1 June 9, 1997 Initial version.
1.3 July 25, 1997 Updated Year 2000 Updates in DIGITAL UNIX Version 4.0D section to include an additional change to the prs command. Also added descriptions of changes to /usr/lib/libpset.a, /usr/sbin/ftpd, /usr/sbin/tcpdump, and /usr/sbin/jdbdump.

Updated General Time-related Updates in DIGITAL UNIX Version 4.0D section with changes to /usr/bin/at, /usr/shlib/libc.so (mktime), and /usr/tcb/bin/edauth.

1.4 September 25, 1997 Updated Testing Methodologies and Guidelines section with 00Y2K-TESTING information and Special Procedures For Expiring PAKs.

Updated Year 2000 Updates in DIGITAL UNIX Version 4.0D section to include additional updates to the /usr/bin/X11/dxaccounts and /usr/bin/X11/dxcalendar components. Also added descriptions of changes to /usr/bin/dtifddif, /usr/lbin/udetect and associated commands, /usr/bin/ltf, /usr/sbin/sendmail, CDE subsystem, /usr/dt/share/examples/dtdnd/*.c, and /usr/bin/X11/xterm.

Updated Year 2000 Features Added in DIGITAL UNIX Version 4.0D section with new information about lmf enhancements and the y2ksniff tool.

1.5 November 3, 1997 Updated DIGITAL UNIX Versions 4.0B and 4.0C and DIGITAL UNIX Version 4.0A and Earlier to clarify the Y2K enhancements available for these versions. Also emphasized that full Y2K support is available only in DIGITAL UNIX Version 4.0D or later.

Incorporated several editorial changes for stylistic reasons.

1.6 December 8, 1997 Updated distribution information for DIGITAL UNIX Y2K test PAK (00Y2K-TESTING).
1.7 February 19, 1998 Updated references to DIGITAL UNIX Version 4.0D to clarify that this release is currently available.
1.8 March 30, 1998 Fixed several minor typographical errors.
1.9 April 3, 1998 Updated link for Compaq layered software product Y2K status.
2.0 October 8, 1998 Updated document to reflect the company name, logo and copyright notice for Compaq Computer Corporation. Also added section Year 2000 Patches for DIGITAL UNIX Version 4.0D and descriptions of Y2K enhancements provided in the patch kit for Version 4.0D.
2.1 October 15, 1998 Clarified current & scheduled availability of specific Year 2000 Patches for DIGITAL UNIX Version 4.0D.
2.2 October 28, 1998 Removed DIGITAL UNIX logo.
2.3 November 25, 1998 Added Year 2000 Readiness Disclosure.
2.4 January 21, 1999 Updated document to reflect Tru64 UNIX product name and logo where appropriate.
2.5 February 22, 1999 Clarified Year 2000 readiness of releases after DIGITAL UNIX Version 4.0D.
2.6 February 26, 1999 Changed ASAP Program reference to new Compaq Solutions Alliance with appropriate URL.
2.7 March 1, 1999 Updated for minor appearance changes.
2.8 March 17, 1999 Clarified warranty application and associated links.

Return to top of page