On Thu, 15 Apr 2004 09:00:32 +0200, Cyrille Dupuydauby wrote
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).
Thx for the post Cyrille. I always like to hear about these sorts of experiences. I've seen exactly this sort of problem arise as well which was one of my motivators for writing the library.
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).
Yes, add_year and add_month have the same problem. I consider these logical operations. add_days and add_weeks are, however, perfectly defined and obey normal mathemtical rules.
IMHO, add_month should follow this rules : ...snip rules...
I'm going to address your rules and issues in an upcoming summary post...
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.
I would very much like to hear about these requirements. Not that I believe that the library should support all of them directly -- only that the library facilities should make it to implement these. Jeff