From: Val Samko <boost@digiways.com>
Tuesday, April 13, 2004, 11:25:52 PM, you wrote:
Do you actually need such a functionality in any applications?
RS> No. The point I was making is that were I to call such a RS> function, that's the behavior I'd expect. Does not having a RS> current need for it make it less valid?
I think it does. One could think of 10 other behaviours of add_month, starting from the random day of the next month, but they would be nothing but useless. And I can not imagine any real use for the add_month behaviour you have described.
Clearly you think my notion of adding a month is akin to randomly selecting a day in the next month. Thanks. I hadn't realized my mind was so odd. Seriously, when I schedule something for a month hence, I'm not concerned about whether that entirely skips the month of February unless it is an event that is supposed to be the 3rd Tuesday of the month, or something. Instead, I want it to be about 1/12 of a year in the future. Consider using a natural language task scheduler that permits scheduling things with phrases like "tomorrow," "next week," and next month." I'd expect "next month" to mean increment the month and clip to the number of days in that month. However, if I could type "a month from now," I'd expect it to add 1/12 of a year; that is, I'd expect 30 or 31 days from now.
RS> It isn't mathematical, by which I meant predictable, without RS> accounting for whether the day of the current month is available RS> in the subsequent month. That is, yours may fall back anywhere RS> from zero to three days. Mine is certain to advance to the same RS> day of the month or exactly 30 days beyond the start; that's far RS> more predictable. Predictable? It is definitely not predictable. I think, most people expect that after d2 = add_month(add_month(d1, 1), -1) d1 and d2 are in the same month. And your definition breaks this obvious rule.
When did we start discussing negative increments? Wouldn't that be called subtract_month()? Really, though, let's follow your logic using January 30th. add_month(d1, 1) gives you February 28th (maybe 29th). Then, add_month(d2, -1) gives you January 28th. How is that logical? Now let's examine my logic in that context: January 30th to March 1 to February 1. Which gives a better answer? Neither. Yours offers the benefit of returning to the same month, but neither returns to the same date which means it is simply not a reversible operation. Consequently, your argument is specious. Given my natural language scheduler example, I'm led to suggest what you want is "next_month" and what I want is "add_month." That is, the names are distinct for the distinct behaviors and "next_month" clearly -- to me -- connotes what you're asking for. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;