>Well, it may not be documented in Help, but it is in HackFox <g>.

I actually looked there and I missed it, I guess because I was only looking for the little bug icon. Now I know I need to read too.



>That's how I knew. Ted knows all this esoteric stuff about dates.

It's an amazing book, it's so incredible that a human would know almost EVERYTHING!



>I don't think it's unreasonable for the function to work only in the range where its results make sense in a large portion of the world. That is, they know that calculating by months fails at some point because of the adjustments to the calendar when countries switched to Gregorian. Different countries changed at different times. They could have picked any of those dates as the cut-off for GOMONTH(). Not choosing one of them would have been irresponsible, I think. 1752 was a good one because the British Empire was a fair chunk of the world and, more importantly, takes in a significant portion of the places where VFP is used. The other reasonable choice would have been 15xx (I forget exactly) when the Gregorian calendar was first introduced.

I disagree here, my point was that it doesn't make any more sense to go beyond 1753 (or 1582) using ANY date calculation in FP/VFP, than using gomonth().
If gomo(date(),-(year(date())-1752)*12) doesn't make sense and should return an empty date, why date()-(year(date())-1752)*365 makes sense and returns a 1752 date. I believe that, for the sake of consistency, gomonth() should return dates as all other date calculations in FP/VFP. As Bob said,




>However, it should be documented in Help. Garrett, you putting that through as a doc bug?

I'd vote for making gomonth() return dates the same as other date calculation, rather that document it. But, now that I know, I can live with both.
Thank you for your time, and thank you for the Hacker's Guide.