From: Val Samko (boost_at_[hidden])
Date: 2004-04-13 04:55:06
Monday, April 12, 2004, 3:26:40 PM, you wrote:
RS> From: "Jeff Garland" <jeff_at_[hidden]>
>> 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?
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
Since falling back is somewhat common expectation, having documented
it properly, it would be natural to have the add_month function. Other
variations (since less common) may have other names.
Anyway, what other variations do you propose, which can not be
achieved by just adding N days?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk