Re: [boost] Re: Date-Time

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-04-17 13:40:58

Sorry to not be able to keep up with this in real-time.  Since I haven't, let
me try to summarize.  I've responded to a few discussions independent of this
email.

1) There is broad agreement that the library should offer functions for adding
months.  If for no other reason than the complexity of the issue as
demonstrated by this email thread.
2) There is no overall consensus for the best name and form of these
function(s).  Sticking with the pure function names for a moment, Rob and 
others suggested the following names:
  next_month
  increment_month

Just as a note, the JAVA library calls this 'roll' -- which doesn't quite do
it for me, but just offering other altenatives. 
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Calendar.html 
  
2) Behavior of 'add_month'.  Ignoring the name of the function for a moment...
2a) Exceptions / not_a_date_time when adding past the end of the month:
These seemed to be the least liked behaviors.  
2b) Reversability
One of the major concerns seems to be reversibility of calculation.  I think
in general this property cannot be provided with a 'logical function' unless
you have a complete memory of all calculations.  Needless to say, the 'date'
class is not the place to provide this.  

This is hardly the only place in date_time where these sort of issues crop up.
 Once upon a time Michael Kenniston wrote up this point in some detail.  It's
not specific to adding months, but I believe it comes down to some of the same
core issues.

http://www.boost.org/libs/date_time/doc/Tradeoffs.html

Bottom line, if you want reversability at the date level everything needs to
be done in terms of days and weeks.

Also, I believe the month_iterator provides a limited level of reversability
if you need with the 'end of month snap behavior'.  In 1_31 it is now
bi-directional so if you iterate forward and then back you get the same

month_iterator mitr(date(2000,Jan,31));
mitr++; //feb 29 -- will be feb 28 in non-leap-years
mitr++; //mar 31
mitr--; //feb 29
mitr--; //Jan 31

4) Non functional alternatives
Dave and I like the idea of non-functional alternatives. Gary, Rob, and Val
are against it on the grounds that the non-intuitive behavior makes it
dangerous.  Per my 'date-generators' email, I'm still interested in this, but
I think it should be built on a functional base.

5) Implementing LAST-1, LAST-2, etc
At the very beginning of this thread I agreed that having functions like:
  date d(...);//arbitrary date
  date fd = first_date_of_month(d);
  date ld = last_date_of_month(d);

would be valueable additions. LAST-2 can be trivially implemented for fully
specified dates as follows:

  days_before_end_of_month(const date& d, days days_before)
  {
     return last_date_of_month(d) - days_before;
  }   

However, it might be useful to have another date generator which would not
require a full date and could represent the last day of the month variants. 
I'm thinking something like:

  last_day_of_month ldom; 
  date d = ldom.getDate(2003, Feb); //feb 28
  before_last_day_of_month ldom(2); 
  date d = ldom.getDate(2003, Feb); //feb 26

Jeff