Boost logo

Boost :

From: Val Samko (boost_at_[hidden])
Date: 2004-04-13 04:55:06


Rob,

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
RS> parameter.
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?

Val Samko
http://val.digiways.com


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk