Hi, I have worked for a french accountancy and sales management software company for many years and we have big needs in date calculation and would ba happy to find a standard class covering our needs. We ended up having multiple date classes because people were unable to agree on topics such as this one. I even tried do create a 'final' date class which tried to merge the others (half a success because of too much interface disparity). The debates we had here and this thread prove that you cannot have a parameterless add_month(...);this is no trivial operation; by the way, this means no add_year(...) also (due to the 29th feb). IMHO, add_month should follow this rules : - be reversible; either by having a negative number of month as a paremeter, or by using sub_month, so that sub_month( add_month(d) ) == d; for every valid date d. - if used twelve times it should be able to give you the same date one year from now (except for the 29th feb of course). - if it can be parametrized using a number of month, adding n months should be equivalent to adding n times a month (and any other combinations for a total of n months). - the user should be able to specify the expected behaviour: - saturation ( never go past the end of next month): most expected behaviour I guess - end/begin ( from last-n to last-n next month with n<4-5): this THE standard behaviour for payments date. - overflow ( going from 31 january to 1-3thd march): not reaaly needeed because you can achieve the same results adding 30/31 days to current date. - eventually others to be define. what we cannot have : - a simple add_month(...) prototype hiding the complexity involved. - use fake dates for thing such as LAST because this state would probably be lost during seralization. - throw an exception for complex case: IMHO offering exceptions as an extension mechanism is bad design. - use 'virtual' days (30th Februray) because this state would probably be lost during seralization and would never be accepted by a DB engine. For us, date is a basic type needeed everywhere and we NEED month calculation, that's why we keep designing date classes. We have funkier date calculation algorithms which would not fit in a standard class, but I will gladly explain them if someone wants to. Cyrille Dupuydauby