>>>>>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...

No, there are actually some dates that do not, nor have they ever, existed! The dates that are skipped (sometime in October 1752?) VFP will let you store a date value for those non-existing dates, and that's what will give you an "incorrect" answer for the DOW()/CDOW() function for dates that are earlier than the skipped ones. The algorithym does not compensate for the "skipped" dates.