Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-04-17 12:06:59


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk