Re: [boost] Date-Time

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-04-14 10:45:18

From: Val Samko <boost_at_[hidden]>
> Tuesday, April 13, 2004, 11:25:52 PM, you wrote:
> 
> >> Do you actually need such a functionality in any applications?
> 
> RS> No.  The point I was making is that were I to call such a
> RS> function, that's the behavior I'd expect.  Does not having a
> RS> current need for it make it less valid?
> 
> I think it does. One could think of 10 other behaviours
> of add_month, starting from the random day of the next month, but
> they would be nothing but useless. And I can not imagine any
> real use for the add_month behaviour you have described.

Clearly you think my notion of adding a month is akin to randomly
selecting a day in the next month.  Thanks.  I hadn't realized my
mind was so odd.

Seriously, when I schedule something for a month hence, I'm not
concerned about whether that entirely skips the month of February
unless it is an event that is supposed to be the 3rd Tuesday of
the month, or something.  Instead, I want it to be about 1/12 of
a year in the future.

Consider using a natural language task scheduler that permits
scheduling things with phrases like "tomorrow," "next week," and
next month."  I'd expect "next month" to mean increment the month
and clip to the number of days in that month.  However, if I
could type "a month from now," I'd expect it to add 1/12 of a
year; that is, I'd expect 30 or 31 days from now.

> RS> It isn't mathematical, by which I meant predictable, without
> RS> accounting for whether the day of the current month is available
> RS> in the subsequent month.  That is, yours may fall back anywhere
> RS> from zero to three days.  Mine is certain to advance to the same
> RS> day of the month or exactly 30 days beyond the start; that's far
> RS> more predictable.
> Predictable? It is definitely not predictable. I think, most people
> expect that after
>    d2 = add_month(add_month(d1, 1), -1)
> d1 and d2 are in the same month. And your definition breaks this
> obvious rule.

When did we start discussing negative increments?  Wouldn't that
be called subtract_month()?

Really, though, let's follow your logic using January 30th.
add_month(d1, 1) gives you February 28th (maybe 29th).  Then,
add_month(d2, -1) gives you January 28th.  How is that logical?

Now let's examine my logic in that context:  January 30th to
March 1 to February 1.  Which gives a better answer?  Neither.
Yours offers the benefit of returning to the same month, but
neither returns to the same date which means it is simply not a
reversible operation.  Consequently, your argument is specious.

Given my natural language scheduler example, I'm led to suggest
what you want is "next_month" and what I want is "add_month."
That is, the names are distinct for the distinct behaviors and
"next_month" clearly -- to me -- connotes what you're asking for.

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