I got the same thing as you Bob, except I have strict date set as 2. I think that you have to have strict date set on.

>With strict date level set to 1 from options NOT A SINGLE ONE of the print statements below printed. I either got an invalid date message or an ambiguous date message.
>
>However, setting strict date level to 0 produced the same results you outlined below.
>
>>>>Ed,
>>>>
>>>>I think we're seeing a difference in how 5.0 and 6.0 handle this situation. Brenda stated (and I'm using) 6.0. Our results were the same, your's different.
>>>
>>>I cannot prove it right now, but I do not believe in this. The issue is too serious to allow so large version incompatibility.
>>
>>Ed,
>>
>>I'm sorry that you don't believe in it, but that's what happens. Maybe someone else using VFP 6.0 can validate it. Here's the code, right from my command window (with the results as comments):

>>? {^0000-03-01} && 03/01/0000
>>? {03/01/0000}  && 03/01/0000
>>? {^000-03-01}  && 03/01/0000
>>? {03/01/000}   && 03/01/0000
>>? {^00-03-01}   && 03/01/2000
>>? {03/01/00}    && 03/01/2000
>>? {^0000-02-01} &&   /  /
>>? {02/01/0000}  &&   /  /
>>? {^000-02-01}  &&   /  /
>>? {02/01/000}   &&   /  /
>>? {^00-02-01}   && 02/01/2000
>>? {02/01/00}    && 02/01/2000

>>According to the VFP 6.0 help, the rollover clause only applies to entries where the century portion is not entered. Any number of digits greater than two indicate a century portion. This same statement does not appear in the 5.0 help file.