Both MIS professionals and end-users have become accustomed to the two-digit representation of year. Displayed on application maps (or screens) and reports the two digit year is easily recognized and understood. When users see a date of 04/01/96, they immediately recognize April 1, 1996. Similarly, when they see a date of 04/01/00, they will immediately recognize April 1, 2000. The century change will not inhibit our ability to recognize dates on reports and screens, however, it will seriously impact the database representation and code processing.

It is important to understand when a two-digit year representation in a database is a problem. In many instances, the two-digit representation is still perfectly valid. If a date is not part of a sort control field, it probably can continue to be represented with two digits. Dates that are essentially attributes in an entity record (i.e. birth date, employment date, etc.) can continue to exist with a two position year. Similarly, if a series of records are stored in chronological sequence (i.e. LAST) in a set, even if they contain a date field, the YYMMDD representation will continue to be valid. The sort sequence is maintained by the LAST option in the set definition.

The problem arises when the date is part of a sort sequence -- whether in a database as part of a sort control field or in subsequent batch processing after the date has been extracted and becomes part of a sort control element. When the data in a YY field changes from "99" to "00", the year 2000 sorts before 1999 (or even 1901 for that fact). Similarly, problems can arise if a program compares dates.

While I have your attention - here are a couple of other little items for everyone to consider.

The Y2K effort is a pure expense. By making the applications Y2K compliant - sales will not increase. This effort is necessary just to keep your company in business. Since it is an expense - get it over as quickly and as inexpensively as possible, with the minimum impact to the end-user community.