I got out my Clipper 5.0 manual, dated 1990, and on page 1-31 of "Reference" it says:

"Clipper supports all valid dates in the range 01/01/0100 to 12/31/2999 as well as a null, or blank, date." In case you're not on Clipper 5, I remember the Clipper 1.0 manual, such as it was, stating that the Clipper date format could support dates up to 2050 A.D. If your app isn't handling dates, the limitation could be your code, your DOS, or your machine BIOS.

Several of my Y2K DOS issues were solved by using the DOS Date command and typing in the correct date with the explicit 4-digit year. The BIOS couldn't do the rollover, but once it was told "01-03-2000" it was able to keep the clock right, even after a cold boot.

Regardless of SET CENTURY, explicit century data such as CTOD("01/01/2000") will be stored with the correct century. If SET CENTURY is ON, you can enter a 4-digit year in an @...GET . Clipper 5.0 also has SET EPOCH, which is like the VFP ROLLOVER clause:

SET EPOCH TO 1960
?CTOD("05/27/1904") // --> 05/27/1904 (explicit century)
?CTOD("05/27/67") // --> 05/27/1967
?CTOD("05/27/04") // --> 05/27/2004
*Date is assumed to be in the 100 years following the year of SET EPOCH.

The only xBase app I ever saw that was destined for century problems was SBT accounting, because they stored their dates in Character fields. I think your problem may well lie somewhere else.