Re: [boost] date-generators (was Date-Time)

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-04-19 13:22:53

From: "Jeff Garland" <jeff_at_[hidden]>
> On Thu, 15 Apr 2004 09:56:55 -0400 (EDT), Rob Stewart wrote
> > Curiously, though, no one has mentioned "next month" as in the
> > same day of the same week of next month, or the same ordinal day
> > of the week of next month.  You could say that these are much
> > more specialized, and don't need to be handled by the library,
> > but think about regular first Monday of the month meetings or
> > other similar scheduling needs.  Don't those deserve some
> > attention?  Isn't what you've been asking of add_month() really
> > just a case of this broader functionality?  That is,
> > you want next_month(d, n, same_day_of_month_or_fall_back), but
> > others may want next_month(d, n, same_ordinal_day_of_week), etc.
> 
> Yes, I think this deserves attention and it is already supported in the
> library.  There are a set of 'date generator' classes in the library that
> support the generation of a date from logical information like: last Monday in
> January:
> 
> last_kday_of_month lkm(Monday, Jan);
> //supply the missing data to generate a concreate date -- year in this case
> date last_mon_jan_2004 = lkm.getDate(2004); //26th 
> date last_mon_jan_2003 = lkm.getDate(2003); //27th

Yes, I see them.

> I'm starting to think this is where the next_month functionality should
> belong.  Because it allows for the library to easily support a variety of
> different algorithms.  And user extensions can follow the same model so as to
> make custom behaviors integrate seemlessly.

That does make sense, but so does the "date wrapper" idea.  The
latter provides a convenient means to use operator overloading
meaningfully while making the behavior of those operators
specific to the wrapper type.  I think the date wrapper approach
will prove easier to use, but more cumbersome to implement.

> So, I'm thinking something like:
>   increment_month_with_end_of_month_rollback add_quarter_year(3); 
>   date d(...); //whatever
>   d = add_quarter_year(d);
> 
> BTW, I'm still not opposed to other syntaxes and first class representations
> of months to allow simplified syntax.  However, I think that this would need
> to build on top of a pure functional foundation.

With the "date wrapper" idea, I'm not sure this holds.

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