These additions return the year as a four digit number (e.g. 01/21/2000) instead of the two digit number (e.g. 01/21/00) now returned by the current control functions.

Must Make Year 2000 Plans Soon

If any user plans on not running on Unibase by DMAC release 7.42i or later by the time that they need next century dates, they need to let us at DMAC know so that together we can supply a least cost solution for them.

Even Idiosyncracies Carry Over

The new control functions respond exactly (including idiosyncracies) as the mirrored control functions.

Industry Is Using Two Approaches

There are two common approaches to the change in century problem now supported by the Unibase by DMAC environment.  1. Specifically test for dates less than say 50 (fifty is an arbitrary date less than all current dates used as an example) and add 100 to them; then, subtract 50 from all dates for sorting and comparison. (This approach will have to be changed again in 2050.)  2. Replace all current dates with a new date which has the year as four digits and then sort or compare.

All Programs Mixing Dates Change

Either way, programs which have both this century and next century dates must be modified before users start entering data with next century dates.

Go Forward with New Functions

Unibase by DMAC users should use the new control functions and four digit years for new programs. If all the programs are going to be replaced before the new century, then by using the date with the year as four digits on new code will automatically eradicate turn of the century date problems.

This is a non-trivial problem for any existing programming language programs using dates. Users should provide the effort to implement turn of the century changes to avoid last minute rush.