Sorry to not be able to keep up with this in real-time. Since I haven't, let me try to summarize. I've responded to a few discussions independent of this email. 1) There is broad agreement that the library should offer functions for adding months. If for no other reason than the complexity of the issue as demonstrated by this email thread. 2) There is no overall consensus for the best name and form of these function(s). Sticking with the pure function names for a moment, Rob and others suggested the following names: next_month increment_month Just as a note, the JAVA library calls this 'roll' -- which doesn't quite do it for me, but just offering other altenatives. http://java.sun.com/j2se/1.4.2/docs/api/java/util/Calendar.html 2) Behavior of 'add_month'. Ignoring the name of the function for a moment... 2a) Exceptions / not_a_date_time when adding past the end of the month: These seemed to be the least liked behaviors. 2b) Reversability One of the major concerns seems to be reversibility of calculation. I think in general this property cannot be provided with a 'logical function' unless you have a complete memory of all calculations. Needless to say, the 'date' class is not the place to provide this. This is hardly the only place in date_time where these sort of issues crop up. Once upon a time Michael Kenniston wrote up this point in some detail. It's not specific to adding months, but I believe it comes down to some of the same core issues. http://www.boost.org/libs/date_time/doc/Tradeoffs.html Bottom line, if you want reversability at the date level everything needs to be done in terms of days and weeks. Also, I believe the month_iterator provides a limited level of reversability if you need with the 'end of month snap behavior'. In 1_31 it is now bi-directional so if you iterate forward and then back you get the same month_iterator mitr(date(2000,Jan,31)); mitr++; //feb 29 -- will be feb 28 in non-leap-years mitr++; //mar 31 mitr--; //feb 29 mitr--; //Jan 31 4) Non functional alternatives Dave and I like the idea of non-functional alternatives. Gary, Rob, and Val are against it on the grounds that the non-intuitive behavior makes it dangerous. Per my 'date-generators' email, I'm still interested in this, but I think it should be built on a functional base. 5) Implementing LAST-1, LAST-2, etc At the very beginning of this thread I agreed that having functions like: date d(...);//arbitrary date date fd = first_date_of_month(d); date ld = last_date_of_month(d); would be valueable additions. LAST-2 can be trivially implemented for fully specified dates as follows: days_before_end_of_month(const date& d, days days_before) { return last_date_of_month(d) - days_before; } However, it might be useful to have another date generator which would not require a full date and could represent the last day of the month variants. I'm thinking something like: last_day_of_month ldom; date d = ldom.getDate(2003, Feb); //feb 28 before_last_day_of_month ldom(2); date d = ldom.getDate(2003, Feb); //feb 26 Jeff