What is DATEADJ?

DATEADJ is an Alpha Four keystroke script that adjusts partially-entered Dates in Alpha Four. It can bring true Year 2000 Compliancy (Y2K) to the Alpha Four environment. It will work with any Alpha Four Version 3, Version 4 and Version 6 and up works with American or European style dates. Full, documented code is provided to allow for modifications.

It requires minor editing of all Database and Set fieldrules and small modifications to all scripts that get date information from a user input.

It's basic functions include;

1. Fills 2 digit years with a 4 digit year in a 100-year window of a reference date (normally the system date)
2. Fills month and day with leading zeros, e.g. "1/8/1998" -> "01/08/1998"
   (Mostly used as a common routine by other scripts)
3. Fills blank year with current year, e.g. "01/08/" -> "01/08/2003"
   (This corrects the year 0100 problem that many A4 users have)
4. Fills blank day and year with current day and year, e.g. "02/ /" ->"02/15/2003"
   (used for assigning a date several months in the future)

If you would like to know what issues are involved in Y2K compliancy for Alpha Four, See below or Click Here

Price
A multi-user/network license is available for $75 U.S. dollars (Massachusetts residents must add 5% state sales tax) plus shipping & handling. The license is good for use on an either a 1 site (defined as one physical building with a maximum of 75 computer systems accessible to applications using the software) or 1 application (maximum 75 copies of the same application) basis. Additional licensed users can be added. Please contact Computer Systems Design & Associates for details.

A single user, non-networked license is available for $20 U.S. dollars (Massachusetts residents must add 5% state sales tax) plus shipping & handling.

Technical Support
Technical Support on DATEADJ is available Alpha 4 consulting rates.

The definition of what Year 2000 Compliancy requires is not universally agreed upon in the industry. Thus, whether Alpha Four or Alpha Five is Year 2000 compliant depends upon your definition. There are several issues at hand.

• 1. Storage of 4 digit years in date fields
• 2. Proper date arithmetic functions for any valid date
• 3. Exporting of dates

All versions of Alpha Four and Alpha Five are compliant in the above 3 items except that Alpha Five Version 1.x fails #2 above partially. It had a bug in the ADDMONTHS and ADDYEARS functions when a resultant year would be a leap year. For those interested in a fix for this bug solution, I published a solution in Alpha Forum Magazine (www.alphaforum.com) in the Q&A column on the April 1996 issue, Page 10.

• 4. Display of Dates
• 5. Entry format of dates

For some Year 2000 Compliancy requirements, the entry of dates must be in a non-ambigous format, e.g. American (mm/dd/yyyy) vs European (dd/mm/yyyy) date formats add enough confusion so that it should always be entered either as yyyymmdd or something like 03 Jul 1998. You can set the format for display on layouts of date fields, which addresses Item # 4 (but this is not the default, and hence must be done manually when creating layouts). When you actually move into the field on a Form or Browse layout to enter or change the value, the entry format is either mm/dd/yyyy or dd/mm/yyyy depending upon the American/European date setting. Thus Alpha Four and Alpha Five would not be compliant if Item # 5 is a requirement.

• 6. Importing of dates with only 2 digit years

For all the various file formats that Alpha Four and Alpha Five can import, it is not clear whether the Alpha Four Version 6.2 or later or Alpha Five will extend any Year 2000 compliancy support it has built-in to imported date fields. At best, it will do the same as it does for date entry of fields, and at worst, do nothing or apply the wrong century. Verifying by testing for the specific import format is the safest course of action. If this does not provide the level of Year 2000 Compliancy that you need, then the date should be imported as a character field. Then perform a global update of a date field to use a converted value of the character field.

It is extremely easy for non-Y2k data (even if it appears to be Y2K with 4 digits) to be imported into your application. NEVER TRUST OTHERS TO HAVE DONE THE CORRECT CONVERSIONS WITHOUT ROUTINES TO CHECK THE DATE VALUES. This is a recipe for disaster.

• 7. Entering 2 digit year in a date field
  (ignoring the blank, 1 and 3 digit year cases)

When a 2 digit year is entered, Alpha Four Version 6.2 will enter in either a 19 or a 20, whichever the Century global configuration item is set to. Earlier versions enter a 19 (See below info about whether you can use Alpha Four version 6.2) in most cases. (Version 4 and earlier may enter a year of 0100 for a 2 digit year entry of 00 as well as other anamolies). Since the Century value in version 6.2 does not dynamically change on January 1, 2000 this may be issue of non-compliance. Alpha Five is a bit better in that it allows you to specify a year where dates before and after get assigned different centuries, but since it applies to all fields, rather than on a field-by-field basis, it still fails the situation described below.

Another reason that you may consider it to be non-compliant is because of the following; Suppose the Century setting is set to a 20. The year is 2003, and you enter in a person's birthday as 02/14/70. With the "20" setting, it will make this date 02/14/2070, instead of the correct 02/14/1970 (since we did not know the person was going to be born that day in the future!). Similar things happen in reverse for expiration dates.

Two solutions exist to address this problem.

One is to force users to enter in all 4 digits of the year's date with a Field Rule validation expression for the date fields. Each date field for all Databases and Sets must have it's field rule validation rule set to an appropriate expression Users often hate this solution as it requires them to type more (especially if they do a lot of data entry - more typing also means more typing errors too). Also, this method will work on all newly entered or changed records, but cannot fix imported data or records that were based on imported data that only contains 2 digit years.

The other way is more complicated and not trivial to create, but can work with Alpha Four version 3 and up. My firm engineered a solution using Keystroke & Trigger Scripts that can be applied as a generic solution. The value is always adjusted to be the correct date. But this solution requires you to know some information about the nature of the field (e.g. a birthdate, expiration date, etc.) and possibly when it was entered or changed (e.g. Create Date field, Updated Last Date field etc.)

Can you use Alpha 4 Version 6.2?
Since Version 6.2 has several operational problems when menu bar is in effect (e.g. the mouse does not select form buttons, form tabs etc., jumping to other fields, etc.), it makes version 6.2 virtually unusable for many applications. This forces some to use the 6.1 or 6.0.11 version, which does not have the century setting at all.

Hardware Compatibility
The PC's ability to keep a system date past a certain date is also a small issue affecting Alpha's system date value. This can often be solved by either updating your BIOS, updating your CMOS clock chip on your motherboard (Some boards have a replaceable Dallas Chip/battery module), Installing a software driver to correct the problem or using an Operating System (like Win 98) that corrects the problem if it exists.