The date problem is a result of the common practice of using a two digit year instead of a four digit year. It becomes problematic as the year 1996 is represented as 96. The year 2000 is represented as 00 and may be interpreted as the year 1900. This date format became widely accepted as coding all four year digits takes more storage and becomes quite tedious for data entry. So most applications whether developed in-house by your programmers or purchased from vendors are at risk of failing. It won't take a calendar change to January 1, 2000 to make these applications fail. They may be failing today when trying to perform calculations beyond 100 years. Consider banking applications that calculate interest on a 30 year mortgage. They have faced this problem since 1970. This is just one of many possible date problems.

Sorting a two digit year also comes into question. The two digit representation of the year 2000 will be sorted prior to the two digit year for 1999 as 00' is less than 99'. When the sorted set is then stored in a DBMS you now have a data integrity problem. How about handling a two digit leap year calculation? The year 1900 is not a leap year, but the year 2000 is. If they are both represented as 00 how to distinguish between them? The year 2000 will have 366 days, not 365 so your day calculations will be incorrect. How will you correctly calculate which day is March 1, 2000? It's a Wednesday not Tuesday. The prior Tuesday is February 29, 2000. Remember, its a leap year if the year is evenly divisible by 4 or 400 and not evenly divisible by 100.

Solving the Date Dilemma

First I need to define my exposure by identifying applications which use two digit years. I could run a search across all my 3GL and 4GL code looking for strings such as DATE,YMD,YEAR etc. Or I could use a parse time tool that would let me know that I have made a reference to said strings. But this is just the tip of the iceberg.

Now that I have an idea of the scope of the problem I can begin the daunting task of changing my code. Many techniques may be employed to accomplish this task. They include; windowing your two digit dates without changing your data, conversion to a four digit year format, using a bridge program, or encoding/compression techniques.

Mainframe FOCUS release 7.0.5 employs a sliding date window that allows for the definition of a 100 year span when evaluating two digit dates. Another technique is converting all your two digit code to four digit code. This may be impossible for some IS shops. There's just too many lines of COBOL code. Or worse yet, the source code no longer exists only the executable object remains. Bridge programs such as a date server are another option. These servers handle record format conversions from two to four digit years. Call statements are added to existing code for the date server so it can handle date operations. Encoding/compression a four digit year into a two digit year will use the same amount of storage but requires many programming changes. This is your least favorable option.

Now that you have decided on an approach and your changes are in place you should begin testing them by 1999. Give yourself plenty of time to get them right. And after all this hopefully on January 1, 2000 you won't be paged at home with a system failure on your hands.

Information Builders has adopted a sliding date window approach to solving date conversions into the next century. Your stored data need not change, just the way in which your application references it. In order to see the century of a two digit year it must be expanded via a temporary field such as a DEFINE or COMPUTE to four digits. The century is decided based on the defined 100 year span. Years LT the 100 year span get a century calculated as current century + 1. Years GE the 100 year span maintain the current century. The current century can be the default century which is 19 or a user defined century. Two new set commands are available that provide the 100 year span definition:

SET DEFCENT=nn
SET YRTHRESH=nn

DEFCENT is the default century which begins your 100 year span.
YRTHRESH is the year threshold which begins your 100 year span.

These global SET commands may be issued from FOCPARM, PROFILE, FOCEXEC, or from the FOCUS prompt. They are in effect for the duration of your FOCUS session.

SET DEFCENT=19,SET YRTHRESH=96 is interpreted as a 100 year span starting with the year 1996 and ending with the year 2095. Printing a field in a Master File Description (MFD) that uses a two digit year format (for example FIELD=HIRE_DATE,HD,I6YMD,$) displays as 96/04/15. By using a DEFINE I can expand all records that pass my screening conditions to a four digit year which displays as 1996/04/15. In this example I create a new field called EBHIRE_DATE which has a new eight byte format of YYMD. Notice the YY. This changes a two digit year into a four digit year.

DEFINE FILE MFD
EBHIRE_DATE/YYMD = HIRE_DATE;
END

The original field, HIRE_DATE is known as an 'old date' format. My new field EBHIRE_DATE is know as a new date' format. Why distinguish between the two formats?

FOCUS is a rich 4GL in its ability to describe and format datatypes. It allows formatting options such as YMD to be appended to alphanumeric and integer datatypes. These fields are coded as FIELD=xxx,yyy,A6YMD,$ or FIELD=xxx,yyy,I6YMD,$. Internally these values are stored in the database as an alphanumeric 6 byte and integer 4 byte field. When displayed they will have a "/" after every two positions. So both datatypes can represent date information in a report or as input to a MAINTAIN/MODIFY procedure. These types of formats may also be referred to as old dates'.

Conversely a FOCUS new date' field is really an integer date which is the number of days since December 31, 1900. It is stored in the database as a 4 byte integer. This makes it very simple to calculate the number of days between two dates, or find the date a given number of days before or after a given date.

When determining the scope of your date problem, any field formats coded with a new date format don't pose a problem for date arithmetic. You may have display problems if your new date format uses a 2 digit year, FORMAT=YMD,$. But this problem can also be solved by converting from a 2 to 4 digit year. You will certainly face most of your problems with those ambiguous dates that a search doesn't turn up. Fields that are formatted as alphanumeric 6 bytes or integer 6 bytes which contain date information. How will you know that they contain date information without referencing them directly.

In Mainframe FOCUS release 7.0.6 we introduce an expanded version of the sliding window technique. File and field level settings of DEFCENT and YRTHRESH may be coded in your MFD or directly in DEFINE/COMPUTE statements. This creates much more flexibility in isolating date conversions on a per file or per field level basis. So your 100 year span may slide based upon where the setting is coded.

At the MFD or file level, new syntax has been added:

FDEFCENT=nn {FDFC}=nn

FYRTHRESH=nn {FYRT}=nn

These file level settings are coded in line one of your MFD immediately following

FILE= ,SUFFIX= ,

FILE=MYDATE,SUFFIX=FOC,FDFC=19,FYRT=96,$
SEGNAME=ONE,SEGTYPE=S1,$
FIELD=SSN,SSN,I9,$
FIELD=FIRST_NAME,FN,A10,$
FIELD=LAST_NAME,LN,A15,$
FIELD=HIRE_DATE,HD,I6YMD,$

At the field level, new syntax has been added:

DFC=nn YRT=nn

These field level settings are coded immediately following your FORMAT= , statement.

FILE=MYDATE,SUFFIX=FOC,FDFC=19,FYRT=96,$
SEGNAME=ONE,SEGTYPE=S1,$
FIELD=SSN,SSN,I9,$
FIELD=FIRST_NAME,FN,A10,$
FIELD=LAST_NAME,LN,A15,$
FIELD=HIRE_DATE,HD,I6YMD,$
FIELD=RETIRE_DATE,RD,I6YMD,DFC=19,YRT=50,$

Converting the 2 digit year in HIRE_DATE to a 4 digit year uses a 100 year span beginning with 1996. But any conversions involving the RETIRE_DATE field will use a 100 year span beginning with 1950.

For DEFINE and COMPUTE statements, new syntax has been added:

DEFINE/COMPUTE fld/fmt DFC nn YRT nn = expression;

Like the field level settings, DFC nn YRT nn must be coded immediately following the field format.

Our earlier example using DEFINE and the global settings of DEFCENT and YRTHRESH may now be expanded to:

DEFINE FILE MYDATE
EBHIRE_DATE/YYMD DFC 19 YRT 96 = HIRE_DATE;
EBRETIRE_DATE/YYMD DFC 19 YRT 50 = HIRE_DATE;
END

If you need to use a COMPUTE field which acts on the results of the retrieved and possibly aggregated records, your TABLE request can be coded:

TABLE FILE MYDATE
PRINT FN LN AND COMPUTE
EBRETIRE_DATE/YYMD DFC 19 YRT 50 = HIRE_DATE;
END

So you see that the Date Problem involves not only how you use dates in existing applications but how you manage them for the future. This is a planning and management problem that faces us all. Choices must be made not only for your FOCUS applications but all code used in your shop. The clock is ticking so what are you waiting for?