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

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

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

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.

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.

Jeff