>>>>And GOMONTH() still does not work correctly. ;(
>>>>Try following lines:
>>>>
>>>>SET STRICTDATE TO 0
>>>>tt = {01/01/0003}
>>>>? tt && shows correct date - 01/01/0003
>>>>? gomonth(tt,12) && shows empty date - \ \
>>>>
>>>>GOMONTH() have such behaviour up to {01/01/1752}
>>>>How do you like this bug? ;)
>>>
>>>Hardly a bug. Dates following the Gregorian Calendar did not exist before 1752, so what's it supposed to do, guess? :)
>>
>>
>>Than, how you explain following???
>>tt = {01/01/0003}
>>? tt && shows correct date - 01/01/0003
>>
>>VFP have ability to store all such dates. Some functions even return correct values for them. But GOMONTH() didn't work.
>
>That maybe true, but are those dates truly correct? There was a skip in the calendar back then (when and how many days, I'm not exactly sure of, and I'm too lazy to look it up. :)), but I don't think that VFP correctly calculates the day of the week for those dates.

Its ok, let suggest gomonth({01/01/1752},12) don't work because dates skept. But why it don't works for 01/01/0003???

Finally, these dates stored correctly. They just 4-byte floation-point numbers in memory. For date before certain year these umbers are just negative. When you add 1 to date, you just add 1 to this number, that means 1 day. Time in datetime value stored in fractional part. I see nothing problematic here. Just a bug...