From: Robert Bell (belvis_at_[hidden])
Date: 2004-04-13 18:08:48
Rob Stewart wrote:
> From: Val Samko <boost_at_[hidden]>
>>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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk