>> You say that it is actually kind from VFP to signal that beyond 1753 is uncertain teritory, and I agree.

Well, I think it would be kinder if the limitation were documented <g>.

>> Why then it does this only when you are riding on gomonth().

If you mean, why doesn't the same thing happen with straight date math (e.g., {02/19/1700}-365 ), then I wouldn't hazard a guess. FP2.6 claims to have "worked" with dates as far back as 100AD but in VFP it goes back to 1 Mar 0000, the day before which was 0 Mar 0000 <g>. The whole idea of a reliable Julian or Gregorian date back that far is just laughable anyway.

>> True, it is date math though. I mean, if you don't use gomonth(), what would be the birth
>> date for somebody "Died 30 May 1899 at age 1 month"?

That particular example probably wouldn't generate much debate. Most would conclude a birth date of 30 April 1899.

But my example was "Died 31 May 1899 at age 1 month" from which most genealogists would probably calculate a birth date of "30 April 1899 or 1 May 1899" (or maybe "about 30 April 1899"). In neither case does the answer fit in a date field - which is why apps which deal with historical or otherwise-ambiguous dates usually don't use date-type variables, fields, or functions.

Instead, we rely on character fields and very elaborate UDFs that are geared toward a specific discipline (e.g., genealogy, archaelogy, sociology, etc.), support specific kinds of dates (e.g., before x, after x, between x and y, from x to y, etc.) and with a specific task in mind (subtracting one "date" from another, adding a number of days/months/years to a "date," calculating during between ambiguous dates, etc.)

If you need help writing such a function, then write to me by e-mail and describe what you're trying to accomplish exactly. I'll see what I can do to help.

-Bob