[boost] Re: Re: Date-Time

From: Cyrille Dupuydauby (cyrille.dupuydauby_at_[hidden])
Date: 2004-04-15 02:00:32

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