Rob, 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? 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