Re: [boost] Date-Time

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-04-13 10:46:11

From: Val Samko <boost_at_[hidden]>
> Monday, April 12, 2004, 3:26:40 PM, you wrote:
> RS> 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?
> 
> RS> Adding irregular values is complicated.  Typically, when adding
> RS> "a month" to a date, one expects the same day of the month in the
> RS> subsequent month.  However, if the following month does not
> RS> include the date in question, then my expectation is that adding
> RS> a month means adding 30 days.
> 
> Why 30 days? And if all you need it to add 30 days, just add 30 days.
> You do not need the add_month then. I just do not understand your
> expectations from the add_month function. Can you explain?

I didn't say just add 30 days.  I said I'd expect it to be the
same day of the month in the following month and if there is no
such day in that month, then I'd expect it to be 30 days ahead.

Consider:

   add_month(date(2004, Jan, 30), 1)

Since February doesn't have a 30th day, then I'm saying I'd
expect "one month" more than January 30th to be February 29th, 30
days after January 30th.  Similarly:

   add_month(date(2004, Jan, 31), 1)

I would expect to result in March 1st.

Now, I can understand the idea of recognizing that a date is the
last day of a given month so that adding "one month" means to
advance to the last day of the next month.  However, when I think
of advancing by a month, I think of adding 1/12 of a year.
365/12 is 30.42, or about 30.  Thus, my fallback is to add 30
days.

Now, one might argue that adding a month should just be adding 30
days then, but that is already possible.  I see add_month() as
the means to get closer to the human notion of getting the same
day of the next month, with a clear, mathematical fallback.

> RS> Consequently, add_month() must either be named more specifically
> RS> ("add_month_fall_back," for example), with other variations
> RS> distinguished from it, or you need to specify some sort of policy
> RS> parameter.
>
> Since falling back is somewhat common expectation, having documented

I don't know how common it is, but I certainly have never used it
and wouldn't expect it.

> it properly, it would be natural to have the add_month function. Other

Documented properly, the function can do whatever its author
deems reasonable.  That doesn't preclude mismatched impedence
with users, however.

> variations (since less common) may have other names.
              ^^^^^^^^^^^^^^^^^
So you say.

> Anyway, what other variations do you propose, which can not be
> achieved by just adding N days?

I don't know what other variations may arise.  We've already seen
two, so distinct but clear names already seem warranted.

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