Description:

The output of CTOD() is different opposed to VFP5 (didn't check VFP6, but it will be the same as VFP7 there), due to 2K problems solved. It lists as follows :

SET CENTURY ON         && No ROLLOVER option used.

                       VFP5          VFP7
?CTOD('01-01-0000')    01-01-1900      -  -
?CTOD('01-01-0001')    01-01-1901    01-01-0001
?CTOD('01-01-00')      01-01-1900    01-01-2000

Solution:

There seems no other solution than to adjust the code;
To be fully upwards compatible, it is best to adjust the initializations of dates, instead of adjusting the checks for "lowest dates". In order to understand this, think of calculations on number of dates with the smallest date possible (in VFP5 being pragmatically (see remarks below) the year 1900) and VFP7 giving a numeric overflow (smallest date being the year 0001).

Remarks:

Note that the Help on SET CENTURY in fact deals with the subject with regards to VFP5. However, the change in behaviour as decribed above is not mentioned. Actually, thinking of the fact that the only real (indefinite) solution to the 2K problem (at the time) was working with SET CENTURY ON, this way of working (SET CENTURY ON) didn't cause any problems or anomalies. However, now in VFP7 oppossed to a VFP5 written app, it does.
Just think of records which a PK of dates, them beginning with some base record (accounting programs may do so ...), and these base records won't be found anymore without adjusting the code first (the program will now look for the PK '01-01-0000' instead of '01-01-1900').
Please note that all originated from the, in fact, bug in VFP5 that each year in the 00 (-01th) century resulted in the 19 (18th) century. For example, in VFP5 a ?CTOC('01-01-0015') would come up with 01-01-1915 (and CTOD('01-01-0115') would show the correct 01-01-0115).

It is my opinion that though this bug is solved, it rather explicitly does not imply upwards compatibility, thinking, again, of the "base" dates stored in PK's.
Lastly, but superfluous, all was encouraged by using the dates without century (long before the year 2000), and thus 01-01-00 was used as the smallest date. Nobody could see that this was 01-01-1900 in the internals, as long as we didn't SET CENTURY ON. And we didn't ...