Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-04-15 08:56:55


From: "Powell, Gary" <powellg_at_[hidden]>
> From: Rob Stewart
> >
> >Ummm, OK, you made it work, but why? Why would you want to be
> >able to call add_month() on a date and have it always represent
> >the day before the last day of the month?
>
> date d = August 30;
>
> // add six months.
> add_month(d); // September 30;
> add_month(d); // October 31?

October 30

> add_month(d); // November 30
> add_month(d); // December 31?

December 30

> add_month(d); // January 30
> add_month(d); // February 28/29

According to my scheme: March 1/2

> add_month(d); // March 28? 29? 30? 31?

According to my scheme: April 1/2

> Just looking this there is no way to predict which
> day of the month the last call is going to be. I'd find

So? You'd have to know whether you were passing over February in
a leap year anyway, which adds variability. Neither scheme is
far from August 30 + 7 * 30 days. (According to my quick check,
August 30 + 7 * 30 days would be March 29/30.)

Now, with add_month(d, 7), where d is August 30, the result would
easily be March 30 (add 7 to the month, advancing the year if
needed; if the starting day of the month (30) is not in the
target month, fall back to adding 7 * 30 days).

Since you're adding an irregular value, these differences
shouldn't be surprising in the least.

Now, if there was a next_month() function, I'd expect this
progression:

   date d = August 30;
   next_month(d); // September 30
   next_month(d); // October 30
   next_month(d); // November 30
   next_month(d); // December 30
   next_month(d); // January 30
   next_month(d); // February 28/29
   next_month(d); // March 28/29

and:

   date d = August 30;
   next_month(d, 7); // March 30

Curiously, though, no one has mentioned "next month" as in the
same day of the same week of next month, or the same ordinal day
of the week of next month. You could say that these are much
more specialized, and don't need to be handled by the library,
but think about regular first Monday of the month meetings or
other similar scheduling needs. Don't those deserve some
attention? Isn't what you've been asking of add_month() really
just a case of this broader functionality? That is,
you want next_month(d, n, same_day_of_month_or_fall_back), but
others may want next_month(d, n, same_ordinal_day_of_week), etc.

> it surprising that
>
> (d + year) != (12 * months) + d;

Actually, that expression should easily be an equality. Adding
12 * months to a date should mean to increment the month by 12
and the year by one and that should do the same thing as adding a
year to the date.

> I think you are looking for a simplistic function for a complex
> problem. IMO its a trap for the unwary and should be called out
> as such.

Why is my notion of add_month() "simplistic" and why isn't yours?

> I can see the need for LAST, but my contention is that its not
> enough information to do the least surprising thing.

I don't understand why not. I can understand wanting to get the
last day of each month as you increment from month to month, but
I can't understand needing the second to last day or third to
last day, etc., for any but the oddest situations. LAST seems
like a valuable concept if we don't get the more general
next_month(d, n, last_day_of_month),
next_month(d, n, second_to_last_day_of_month), etc.

> The easiest way to resolve this is to either write a FAQ, and or
> have a dumb rounding month adding function that can screw up the
> dates for those times when "meet you next month" is the right answer.

I can see how you'd think that, given that you want your
preferred behavior to be the "dumb rounding" scheme in the
library. At the very least, I think there should be a
distinction between add_month() and next_month(). Whether the
library ever provides for more complicated schemes is another
matter. (A more general mechanism that applies a rule for
finding the right day of the new month could be abstracted behind
the names "add_month" and "next_month.")

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;

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