On Sun, 11 Apr 2004 05:27:07 +0100, Val Samko wrote
I think it is natural to back up to the last day of the month, if the day we have (i.e. 31 in this case) is not present in that month.
I agree that backing up seems like the most common desire...
I think, the first approach (non member functions) is better, since a) these function do not need to know the implementation details of the date class b) having some other date class I could easily implement equivalent functions, keeping the syntax consistent.
Ok.
JG> date next = ld + months(13);
JG> There are some technical complications with the last syntax, JG> but it should be doable given some time ;-)
Thoughts? what sort of complications? struct months { months(int m) : mo(m){}; int mo; }; date operator + (const date& d, const month& m) { return add_month(d, m.mo); }
Hmm, point taken. That said, if I add this to the library people will (correctly, I think) expect the following: date d1 += months(3); date d2 = d1 - months(2); date d3 -= months(2); date d3 = d3 + months(-2); to work correctly. The code we have sketched so far won't handle this correctly. Going even further, I don't see why the following isn't allowed: ptime t1(d1); //d1 at midnight t1 = t1 + months(2); And I think this same logic applies to 'years' and 'weeks' as well. This would finally unify the arithmetic concepts in the library -- not to mention make an awful lot of date calculation code very clean.
Anyway, I think, three namespace level functions would be sufficient.
As you can see, I have a slightly grander plan, but it should be compatible with your needs. Do you want these functions in CVS now or are you going to patch your release for now? Jeff