University of Connecticut Computer Center
	Date Field Formats and Guidelines

With the approach of the year 2000 soon upon us, it is time to formalize and publish a standard for date-related fields in records, on reports, on screens, etc. as well as outlining alternatives for handling 21^st century dates when field expansion is not possible.

As dates will look a little bit strange anyway starting with 2000-01-01 (e.g. like 1/1/0), it has been suggested that the year 2000 is an excellent opportunity to change to a standard date notation.

Standard for Dates

Wherever possible, date fields should be defined, stored, and displayed as 8-digit numeric fields conforming to the International Standard ISO 8601 format. That standard date notation is:

CCYY-MM-DD or CCYY/MM/DD

where CCYY is the century and year, MM is the month of the year between 01 and 12, and DD is the day of the month between 01 and 31. Of course the dashes (or slashes) would not be stored in the record, but would be used whenever the date is displayed to the user, to improve readability.

There are several advantages to using this standard notation:

• easily readable by software and humans (no internally "packed" or hexadecimal data)
• easily sort-able and comparable without sub-defining or reordering
  • cannot be confused with other popular date notations (the date 03/04/05 could have any of six different interpretations; March 4, 1905, 3^rd of April, 2005, April 5^th, 1903, etc.)
  • consistent with other common notations, where the larger units (hours of time, area codes of phone numbers) are written before the smaller ones (minutes then seconds, or exchange then number then extension).

Year-only fields or year-containing fields (i.e. YearTerm) should likewise have a 4-digit year component to facilitate sorting, comparing, etc.

Database Fields

When the date is being stored in a database or other file system that provide a "DATE" data type (i.e. DB2, FOCUS) then obviously that is the preferred method because then the system is efficiently validating and managing the values allowed and providing the correct options for sorting, computing, comparing, and displaying the dates.

Alternate Formats

An interesting alternative for storing a date field in a sequential or VSAM file where space allows, is to define it as a 10-digit field, consisting of CCYYMMDDYY. The second occurrence of YY is programmatically kept in sync with the first. This allows a simple, straightforward way to get: (1) the full ISO standard date (the first 8 bytes) for sorting or unambiguity; (2) an abbreviated YYMMDD format date (the middle 6 bytes) for comparing with or moving to old 6 digit date fields; or (3) an old style MMDDYY format date (the last 6 bytes) for displaying on reports or screens while transitioning to the new format.

Now what about existing date fields in records that can't be expanded?

When record lengths prevent or extremely complicate the ability to expand date fields, the only alternative may be to adopt a "process oriented" solution. This means that program logic has to be added to every program that uses those fields to correctly interpret a 6-digit year and determine which century it is associated with.

A common process oriented approach is to use a "100-year window". This involves adding logic that interrogates the 2-digit year and says "if it's greater than XX then century must be 19, otherwise century must be 20." The XX value has to be chosen very carefully and consistently across programs, and may need to be a different value for different date fields.

For instance, if the field being evaluated is YEAR-OF-GRADUATION then a value of 50, or 60, or 70 may be appropriate. But if the field is DATE-OF-BIRTH then the value may have to be as low as 10 or 20. And remember, eventually those values will need to change, perhaps in as little as 10 or 15 years. (Don't fall for the reasoning that "the system will be obsolete before then" or "I won't be around when it fails" - that's what we all thought back in the 80's, and here we are!)

Here's another process oriented approach that also involves converting the data. Keep the 2-digit year field, but convert it into an unsigned binary, or hexadecimal field. This way, the year (19)96 is stored as x'60', '97 as x'61', '98 as x'62' '99 as x'63', (20)00 as x'64', '01 as x'65', and so on. Thus, sorting or comparing on the year field will be correct, but displaying will require some extra coding since the hex values will be unprintable.

Any approach to handling dates that doesn't include a 4-digit year, must be consistently programmed across the application, regardless of platform or language. This might mean common subroutines or copybooks that do the date manipulation, and certainly requires extensive testing to ensure that all system components (programs, sorts, control cards, jobstreams, etc.) can process ALL date combinations correctly. And remember, there are probably hundreds of "programs" out there that the users run themselves that will be impacted by a process-oriented approach (or by a date-expansion approach as well).