Re: Re[2]: [boost] Date-Time

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-04-11 10:01:02

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