



Products	Support	Download	Contact

Y2K and Other Date Issues

return to contents or index

Abstract

Largely of historical interest at this point, prior to the year 2000 there was a great rush to make software "Y2K compliant". For the most part XENTIS didn't have any major inherent Y2K-related problems, however there were (and still remain) some issues with some of the legacy date data types which XENTIS supports; some of these issues aren't specifically year 2000, either. For instance the original RSTS date formats ran out of room on December 31, 2002, and some other formats will hit the wall on 31-Dec-2038.

Discussion

XENTIS and OpenVMS by themselves have no problem handling dates fields that specify a date later than the year 2000. In fact, both will handle dates for many centuries into the future. However, the earliest date that either software will process correctly is November 17, 1858.

Hard-Coded issues in Report Definition (XCF) Files

If your date data is stored in your data files in a manner that XENTIS does not recognize as a date, and is not converted by the D1, D3, or D5 functions, then it will be your responsibility to determine to which century the date belongs.

Calculations are particularly susceptible to this, if the person who defines them makes assumptions about the century to which the date belongs.

Date formats with two-digit years

Whenever XENTIS reads a date field that is stored in a data file, XENTIS always converts the date field from the format that is used in the data file to XENTIS' internal date format. If the date data is such that only two digits of the year is stored, then XENTIS needs to make an assumption as to which century the date belongs in.

The following date data types have the characteristic of not being able to distingush to which century a date belongs:

TDA (6 byte and 12 byte instances only)

MDY (6 byte and 12 byte instances only)

DMY (6 byte and 12 byte instances only)

RDA (2 byte instance only)

RDR (2 byte instance only)

In addition, the D1, D3, and D5 calculation functions also face the same dilemma. These functions convert 6 byte text fields or 6 digit numeric fields to a date field.

The YR function returns a two-digit year; use the YEAR function for a four-digit year.

Please note that 2 byte instances of RDA and RDR data types allow dates only for the range 01-JAN-1970 through 31-DEC-2002, but 4 byte instances support dates many centuries into the future. In addition, the 8 and 14 byte instances of the TDA, MDY and DMY data types support dates many centuries into the future. The UDA data type can represent dates for the range 01-Jan-1970 through 31-DEC-2038.

Version-Specific Problems with 12-byte TDA/MDY/DMY fields

The 12 byte versions of the TDA, MDY, and DMY datatypes may interpret date-time fields in the YYYYMMDDHHSS, MMDDYYYYHHSS, and the DDMMYYYYHHSS format rather than the documented formats of YYMMDDHHMMSS, MMDDYYHHMMSS, and DDMMYYHHMMSS. This problem was introduced in version 4.1 and is fixed in version 4.6.

CENTURY-ADJUST Sliding window

All versions of XENTIS through version 4.4 assume that dates with two-digit years belong to the 20th century (1900 - 1999). Versions 4.5 and later provide a setup file parameter named CENTURY-ADJUST that will allow the user to specify a cutoff year that controls the century to which a date belongs. For example, if the value of the cutoff year parameter is 25, then all dates whose year value is less than 25 will be assigned to the 21st century (2000-2099), and all dates whose year value is 25 or more will be assigned to the 20th century (1900-1900). This setup file parameter will apply only to dates whose data types are specified above and to the D1, D3, and D5 functions.