From: Val Samko <boost@digiways.com>
Tuesday, April 13, 2004, 4:46:11 PM, you wrote:
RS> I didn't say just add 30 days. I said I'd expect it to be the RS> same day of the month in the following month and if there is no RS> such day in that month, then I'd expect it to be 30 days ahead.
Do you actually need such a functionality in any applications?
No. The point I was making is that were I to call such a function, that's the behavior I'd expect. Does not having a current need for it make it less valid?
RS> Now, one might argue that adding a month should just be adding 30 RS> days then, but that is already possible. I see add_month() as RS> the means to get closer to the human notion of getting the same RS> day of the next month, with a clear, mathematical fallback. falling back to the last day of the month is a perfect "mathematical" fallback as well. It's just a matter of documentation.
It isn't mathematical, by which I meant predictable, without accounting for whether the day of the current month is available in the subsequent month. That is, yours may fall back anywhere from zero to three days. Mine is certain to advance to the same day of the month or exactly 30 days beyond the start; that's far more predictable.
Anyway, what other variations do you propose, which can not be achieved by just adding N days?
RS> I don't know what other variations may arise. We've already seen RS> two, so distinct but clear names already seem warranted.
I understand this if you actually need the functionality you described in any applications. Otherwise, I'd hate to type add_month_or_fallback_to_last_day each time I need this simple operation.
I don't think it must be that dramatic. If the function is to have a unique name, rather than using one of the other techniques I mentioned, I should think that "add_month_with_fallback" would be sufficient to clarify its behavior. It boils down to this: does everyone but me think the fallback behavior is "correct?" If so, ignore me. I can always implement my own "add_month." If not, then yours should not be *the* definition of "add_month" should it? In that case, shouldn't you mitigate the potential for confusion and allow for different schemes? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;