Rob Stewart wrote:
From: Val Samko <boost@digiways.com>
Tuesday, April 13, 2004, 4:46:11 PM, you wrote:
RS> Now, one might argue that adding a month should just be adding 30 RS> days then, but that is already possible. I see add_month() as RS> the means to get closer to the human notion of getting the same RS> day of the next month, with a clear, mathematical fallback. falling back to the last day of the month is a perfect "mathematical" fallback as well. It's just a matter of documentation.
It isn't mathematical, by which I meant predictable, without accounting for whether the day of the current month is available in the subsequent month. That is, yours may fall back anywhere from zero to three days. Mine is certain to advance to the same day of the month or exactly 30 days beyond the start; that's far more predictable.
I'm not so sure. If I get paid once a month, at the end of the month, I expect a paycheck on January 31, February 28/29, March 31, etc. I would be highly surprised (and annoyed) if my February paycheck arrived on March 2. If the payroll program was using your algorithm I would not get paid again until April 2. Using your algorithm, I can add one to a month and end up two months ahead. I note that your interpretation only differs from Val's when adding one month to January; in all other months your interpretation behaves the same as his. So the argument is about only two or three days a year... The interpretation that makes sense to me is: adding one month means the same day of the next month, unless the date's not valid, in which case I expect moving backwards to the latest date of said month. That's what humans do when you say "next month", so I would think anything else would be surprising. Bob Bell