From: Val Samko <boost@digiways.com>
Monday, April 12, 2004, 3:26:40 PM, you wrote: RS> From: "Jeff Garland" <jeff@crystalclearsoftware.com>
No, not really -- lack of customer request, basically. add_month is a bit complicated in that it is unclear the desired behavior of adding into the 'ragged month end'. Basically the issue is:
date d1(2004,Jan,28); date r1 = add_month(d1,1); //2004-Feb-28, fine date d2(2004,Jan,31); date r2 = add_month(d2,1); //presumably we want to back up to Feb 29? date r3 = add_month(d2,13); //presumably we want to back up to Feb 28?
RS> Adding irregular values is complicated. Typically, when adding RS> "a month" to a date, one expects the same day of the month in the RS> subsequent month. However, if the following month does not RS> include the date in question, then my expectation is that adding RS> a month means adding 30 days.
Why 30 days? And if all you need it to add 30 days, just add 30 days. You do not need the add_month then. I just do not understand your expectations from the add_month function. Can you explain?
I didn't say just add 30 days. I said I'd expect it to be the same day of the month in the following month and if there is no such day in that month, then I'd expect it to be 30 days ahead. Consider: add_month(date(2004, Jan, 30), 1) Since February doesn't have a 30th day, then I'm saying I'd expect "one month" more than January 30th to be February 29th, 30 days after January 30th. Similarly: add_month(date(2004, Jan, 31), 1) I would expect to result in March 1st. Now, I can understand the idea of recognizing that a date is the last day of a given month so that adding "one month" means to advance to the last day of the next month. However, when I think of advancing by a month, I think of adding 1/12 of a year. 365/12 is 30.42, or about 30. Thus, my fallback is to add 30 days. Now, one might argue that adding a month should just be adding 30 days then, but that is already possible. I see add_month() as the means to get closer to the human notion of getting the same day of the next month, with a clear, mathematical fallback.
RS> Consequently, add_month() must either be named more specifically RS> ("add_month_fall_back," for example), with other variations RS> distinguished from it, or you need to specify some sort of policy RS> parameter.
Since falling back is somewhat common expectation, having documented
I don't know how common it is, but I certainly have never used it and wouldn't expect it.
it properly, it would be natural to have the add_month function. Other
Documented properly, the function can do whatever its author deems reasonable. That doesn't preclude mismatched impedence with users, however.
variations (since less common) may have other names. ^^^^^^^^^^^^^^^^^ So you say.
Anyway, what other variations do you propose, which can not be achieved by just adding N days?
I don't know what other variations may arise. We've already seen two, so distinct but clear names already seem warranted. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;