Developing Year 2000-ready Applications - How to write or retrofit your programs to meet Y2K compliance standards

by Jerry Ray

Published 1999-05-01    Printer-friendly version

Much discussion has been presented on the need for programs to be year 2000 ready. In this article, we will look at how to implement Y2K into your Clarion applications, ensuring that they will be ready for the new millennium.

What solutions are available for Y2K readiness?

There have been numerous solutions proposed to make computer programs ready for the year 2000. These include literal inclusion of a 4 digit century in all dates, such as MM/DD/YYYY. This is the safest solution, as it removes all ambiguity from the date stored. It may even be required for certain uses. It does, however, increase the number of digits that must be keyed, unless special coding is included to make the first two digits of the year "20" by default. Another method that has gained in popularity is the "sliding window" technique. This allows the end-user to continue using 2 digit centuries, with the computer intelligently "guessing" which century the date is in. For example, we can say that from 50 years in the past to 20 years into the future is the present era (i.e. the end of the 20^th century and the beginning of the 21^st). So a date of 06/01/98 would be interpreted as the end of the 20^th century (06/01/1998) and a date of 06/01/02 would be interpreted as the start of the 21^st century (06/01/2002).

How does Clarion implement Y2K?

The LONG or DATE variables used for storage will allow accessible dates from January 1, 1801 (standard date serial number 4) through December 31, 2099 (standard date serial number 109211). Because Clarion for Windows stores dates in LONG integers or DATE fields that are converted into strings via picture tokens for display or data entry purposes, both of these techniques are supported, and in fact, are designed to work together in an intelligent way. This is called "Intellidating" in Clarion-speak.

The date picture used to implement the first method is @D2. By simply changing the picture token in the data dictionary for all date fields, you can make your programs immediately accept 4 digit centuries. You can then use the application generator's Synchronize command on the Application menu to update all entry and string fields to the new picture. This provides Y2K compliance if the end-user types all four digits. But it will be much more user friendly to have the program supply most of the info based upon some assumptions. Note that for the Intellidating feature to perform the way that you want it to, there are some things you need to know about assumptions it makes. Also, you need to know how to change its assumptions.

First, the default sliding window used for Intellidating is 80 years in the past to 19 years in the future. The run-time library uses today's date as the test point. So if today's date is 08/01/1999 and the date input by the end-user is 09/30/99, Clarion's run-time library will make the assumption that 99 falls in the 20^th century (i.e. 1999). This is done because 1999 falls between 09/30/1919 and 08/01/2018.

When should I change Intellidating's assumptions?

You should always decide the "category" of each date field. There are three basic categories that I like to consider. First, there is an "event date" category. This makes a record of when a certain relevant event has occurred. For example, the record of a person's birth date is an "event date". It is generally a non-recurring date, but may be needed in a calculation, such as determining a person's age.

The second category of date is the "appointment date or anniversary date" category. This makes a record of when a certain relevant event is supposed to occur. For example, the record of when your insurance premium comes due again is an example of such a date. These dates may or may not be recurring dates. They generally are used in calculations or comparisons.

The third category is the "reference date". This is merely a date that has been recorded for reference purposes. These dates are not used in any calculations or comparisons, but are merely recorded for human reference. Note that depending upon the purpose the date is needed, it may not be enough to say that a human can determine which century that it belongs to, so where ambiguity is present, the date should be placed into one of the other two categories. For example, suppose you are dealing with a customer's birth date but do not intend to calculate it or compare it. You merely want to know, as a human, when it was so you could send a birthday card. In this context, the century is not needed, since you do not care how old the person is (i.e. the month and day are all that is needed for this purpose). On the flip side, suppose you have thousands of customers and you want to recognize all of your octogenarian customers on their birthday. Now a filter is likely to return unwanted records. This date should be classified as an "event date" instead of a reference date.

You will change Intellidating's assumptions based upon what category of date you are dealing with, and according to the most likely defaults. For example, event dates generally have already occurred (i.e. they are in the past). For example, a person's birth date is always in the past. (How could you know someone that hasn't been born yet?) So it is logical that if we are in the year 1999, it is safe to assume that all birthdates are in the 20^th century. When we pass the year 2000, we can only make such assumptions if the vast majority of the records we enter are not new born babies! If that is true, excellent! Program the Intellidate for that field so that most entries are 20^th century dates. If it is not true, find out what is the most likely candidate range and use that as the "sliding window" for that field. For example, if today is 02/01/10, and a birth date given as 03/01/01, we could be talking about a 9 year old boy (possible) or a 109 year old man (not likely), or a 70 year old man that died 39 years ago. It is important that the sliding window be written to accommodate as many dates as possible and still produce the correct date by default.

Note that because you have set the picture token to @D2, the end-user can still manually override the Intellidate. So if the system were written to store the above example as 03/01/1901, and you intended for that to record a child's birth date, the end-user could type in "03/01/2001" and the Intellidate feature would be overridden.

How do I change Intellidating's assumptions?

The picture token used for the date is used to specify the Intellidate assumptions. By using the > parameter in the picture token followed by a number, we specify how many years into the future the "current era" represents. By using the < parameter followed by a number, we specify how many years into the past the "current era" represents. The system will subtract this number from 100 to go into that number of years in the opposite direction.

For example, a picture of @D2>40 means that the "current era" is defined as 40 years into the future from today and 60 years into the past from today. So if today is 06/01/2002, and a date is entered into the field as 09/01/20, the date will become 09/01/2020. If a date of 09/01/41 is entered, the date will become 09/01/1941.

If a date picture of @D2<60 is used, this acts the same way, i.e. 60 years into the past and 40 years into the future. You decide which direction to use, and Clarion handles the rest.

Another example, you could say that all dates were 20^th century dates, by using @D2<99. Or that all dates are 21^st century dates, @D2>99. This might be useful for setting anniversary dates after the first of the new century.

You could use @D2<85 for birthdates for average Americans of all ages. This would include most of the current population, and still be useful without further modification for up to 2015. When you get to that point, of course, change the sliding window to @D2<75 (every 10 years or so -- if your program is still around -- of course it'll still be around - right?)

You should decide what sliding window to use based upon the category of date: Event Date, Anniversary Date, or Reference Date; along with the use for that particular date, and the largest constituency of records that meet the range. This will save the data entry operator the most time. He or she may still enter the entire 4 digit century wherever necessary for that occasional date that falls outside the window, but by being creative, you can keep this to a minimum.

Naturally, the inclusion of a calendar lookup window always helps operators, too. Just make sure that the OCX or VBX control or control template you use is Y2K ready. You may need to deformat the value returned by the control using a picture like @D2<80.

See you next time!

Printer-friendly version

Copyright © 1999-2009 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.

Clarion Magazine ISSN 1718-9942