Re: [boost] Re: Date-Time

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-04-14 11:15:25

From: David Abrahams <dave_at_[hidden]>
> "Jeff Garland" <jeff_at_[hidden]> writes:
> > On Tue, 13 Apr 2004 18:30:46 -0700, Robert Bell wrote
> >> Powell, Gary wrote:
> >> >>Bob Bell wrote:
> >> >>The interpretation that makes sense to me is: adding one month means the 
> >> >>same day of the next month, unless the date's not valid, in which case I 
> >> >>expect moving backwards to the latest date of said month. That's what 
> >> >>humans do when you say "next month", so I would think anything else 
> >> >>would be surprising.

I just noticed that here Bob uses the phrase "next month" when
discussing the behavior of a function named "add_month."  This
justifies the separation I mentioned in another post.

> > I think that 'least suprising' is actually determined by the application.  I
> > can see at least several 'reasonable behaviors'.  
> > 1) Rollback to the end of the month (as Gary points out chained calculation
> > gets weird here).
> 
> reasonable

For some uses, certainly.

> > 2) Throw an exception if an invalid date is generated.  That lets the client
> > app just deal with it.
> 
> reasonable

Yes.

> > 3) Set the returned date to 'not_a_date_time' if an invalid date is
> > generated.
> 
> marginally reasonable.
> very inconvenient.

Agreed.

> > I think Rob's add 30 days on invalid is less common, but not
> > unreasonable.
> 
> I'm not comfortable with it.  It's too nonuniform.

This I don't get.  What's nonuniform about it?  It advances to
the same day of the month in the next month, or by a minimum of
30 days, if it would otherwise be an invalid date.

Look at it this way:

 1  2  3  4  5  6  7
 8  9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31  1  2  3  4
 5  6  7  8  9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28  1  2  3  4

Starting from "30" in the 5th line, advance by a month.  It could
mean four weeks, which means "27" in the next month.  It could
mean 30 days -- as accountants would do (they use 360 day years
in their computations) -- which means "1" in the last line, in
the month after next.  In both cases, "adding a month" means
march through the days of the year according to a formula.

Given the oddball arrangement of our calendar, we expect certain
vagueness when using phrases like "next month" or "a month from
now."  Thus, I don't think it is unreasonable to account for
differing notions, especially when they conform to what people
actually do.  (I contend that my algorithm does fit what people
actually do, at least with the phrase, "a month from now.")

> > In the unreasonable camp I would include:
> > 1) Artificially extend the short months with virtual days -- Yes, I'm told
> > that in some domains they use this technique.
> 
> Hang on a sec.  I think a variation of this one isn't so bad: if you
> ask for the day when it's invalid, it rolls back to the end of the
> month (and there's another way to find out the day number that's
> really stored).  The result is sort of like #1, but where chained
> calculations magically "do the right thing".

Do you mean that you get a date object that "knows" it really
means March 1 based upon adding 1/12 of a year, to avoid
cumulative addition errors, but when queried, tells you its
February 28 (29)?  That's a different type, then, right?

> > Of course as soon as I did something in this domain I would be
> > forced to change my mind on how 'unreasonable' it is. So for me it
> > is becoming ever more clear that I was right to stay out if this
> > very dark cave in the first place.

That's why I started by suggesting that there should be a scheme
to account for differing ideas of what it means to add a month.
Perhaps we have increment_month() or next_month() and
add_month(), where add_month() can be parameterized -- through
whatever technique -- to use different algorithms.

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