Re: [boost] Date-Time

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-04-12 09:26:40

From: "Jeff Garland" <jeff_at_[hidden]>
> 
> No, not really -- lack of customer request, basically.  add_month is a bit
> complicated in that it is unclear the desired behavior of adding into the
> 'ragged month end'. Basically the issue is:
> 
> date d1(2004,Jan,28);
> date r1 = add_month(d1,1); //2004-Feb-28, fine
> date d2(2004,Jan,31);
> date r2 = add_month(d2,1); //presumably we want to back up to Feb 29?
> date r3 = add_month(d2,13); //presumably we want to back up to Feb 28?

Adding irregular values is complicated.  Typically, when adding
"a month" to a date, one expects the same day of the month in the
subsequent month.  However, if the following month does not
include the date in question, then my expectation is that adding
a month means adding 30 days.  No doubt others would have
different expectations (as your example illustrates, of course).
You need to allow for varying expectations of how to resolve this
irregularity.

Consequently, add_month() must either be named more specifically
("add_month_fall_back," for example), with other variations
distinguished from it, or you need to specify some sort of policy
parameter.

One approach for the latter idea is to make add_month() a
function template that takes a policy class template parameter
which is asked to compute the final date should the new month not
include the date.  You can default that parameter to a policy of
your choosing since that leaves room for clients to customize it
as they see fit.

Another approach is to take a third function argument of
enumeration type that tells add_month() which rule to apply.
This restricts the options to those defined by the library, but
it is relatively straightforward.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;