From: Robert Bell <belvis@imageworks.com>
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.
If you want that behavior, you wouldn't use add_month() as Val defined it anyway, because you'd need it to snap to the last business day of the month. Nevertheless, let's assume an application in which you want the snapping to the last day of the month. Val's suggested semantics gives it to you. I have no argument with that. What I'm arguing is that I think "one month from now" means around 30 days hence. Consider making an appointment with someone for "a month from now." Usually that means increment the month and leave the day of the month alone. But when there are fewer days in the following month than in the current month and you're very near the end of the current month, I wouldn't think twice about skipping ahead by 30 days or maybe four weeks (to give yet another interpretation). It's like the difference between reals and fractions with arbitrarily constrained denominators (like on an ordinary ruler). You give up accuracy to stay within the allowable units (say, 1/16ths of an inch or millimeters). I see "add a month" as an approximation that tries to snap to something around 30 days in the future. If the current month has 31 days, then the result would be 31 days hence. If the current month has 28 days, then the result would be 30 days hence.
Using your algorithm, I can add one to a month and end up two months ahead.
No, the month number or the day of the month would advance by two, but you'd only be 30 or 31 days 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...
That's an interesting point. Without thinking about it, I expected it to apply when adding a month to March 31, May 31, etc., but we do arrive at the same answer in each case.
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.
Let's look at the example given in other posts: add_month(add_month(d, 1), 1) If such code -- however those two calls actually come about -- occurs when d is late in January, it only advances by 56 days, well less than 1/6 of a year, with your interpretation. With mine, it would advance by 61 days, which is very nearly 1/6 of a year. Thus, mine gives more predictable results when considering a "month" to be approximately 1/12 of a year, which I do. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;