On Thu, 15 Apr 2004 09:56:55 -0400 (EDT), Rob Stewart wrote
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.
Yes, I think this deserves attention and it is already supported in the library. There are a set of 'date generator' classes in the library that support the generation of a date from logical information like: last Monday in January: last_kday_of_month lkm(Monday, Jan); //supply the missing data to generate a concreate date -- year in this case date last_mon_jan_2004 = lkm.getDate(2004); //26th date last_mon_jan_2003 = lkm.getDate(2003); //27th I'm starting to think this is where the next_month functionality should belong. Because it allows for the library to easily support a variety of different algorithms. And user extensions can follow the same model so as to make custom behaviors integrate seemlessly. So, I'm thinking something like: increment_month_with_end_of_month_rollback add_quarter_year(3); date d(...); //whatever d = add_quarter_year(d); BTW, I'm still not opposed to other syntaxes and first class representations of months to allow simplified syntax. However, I think that this would need to build on top of a pure functional foundation. Jeff