Re: [boost] Re: Date-Time

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

From: Robert Bell <belvis_at_[hidden]>
> Rob Stewart wrote:
> > From: Val Samko <boost_at_[hidden]>
> > 
> >>Tuesday, April 13, 2004, 4:46:11 PM, you wrote:
> >>
> >>RS> Now, one might argue that adding a month should just be adding 30
> >>RS> days then, but that is already possible.  I see add_month() as
> >>RS> the means to get closer to the human notion of getting the same
> >>RS> day of the next month, with a clear, mathematical fallback.
> >>falling back to the last day of the month is a perfect "mathematical"
> >>fallback as well. It's just a matter of documentation.
> > 
> > It isn't mathematical, by which I meant predictable, without
> > accounting for whether the day of the current month is available
> > in the subsequent month.  That is, yours may fall back anywhere
> > from zero to three days.  Mine is certain to advance to the same
> > day of the month or exactly 30 days beyond the start; that's far
> > more predictable.
> 
> I'm not so sure. If I get paid once a month, at the end of the month, I 
> expect a paycheck on January 31, February 28/29, March 31, etc. I would 
> be highly surprised (and annoyed) if my February paycheck arrived on 
> March 2. If the payroll program was using your algorithm I would not get 
> paid again until April 2.

If you want that behavior, you wouldn't use add_month() as Val
defined it anyway, because you'd need it to snap to the last
business day of the month.

Nevertheless, let's assume an application in which you want the
snapping to the last day of the month.  Val's suggested semantics
gives it to you.  I have no argument with that.  What I'm arguing
is that I think "one month from now" means around 30 days hence.
Consider making an appointment with someone for "a month from
now."  Usually that means increment the month and leave the day
of the month alone.  But when there are fewer days in the
following month than in the current month and you're very near
the end of the current month, I wouldn't think twice about
skipping ahead by 30 days or maybe four weeks (to give yet
another interpretation).

It's like the difference between reals and fractions with
arbitrarily constrained denominators (like on an ordinary
ruler).  You give up accuracy to stay within the allowable units
(say, 1/16ths of an inch or millimeters).  I see "add a month" as
an approximation that tries to snap to something around 30 days
in the future.  If the current month has 31 days, then the result
would be 31 days hence.  If the current month has 28 days, then
the result would be 30 days hence.

> Using your algorithm, I can add one to a month and end up two months ahead.

No, the month number or the day of the month would advance by
two, but you'd only be 30 or 31 days ahead.

> I note that your interpretation only differs from Val's when adding one 
> month to January; in all other months your interpretation behaves the 
> same as his. So the argument is about only two or three days a year...

That's an interesting point.  Without thinking about it, I
expected it to apply when adding a month to March 31, May 31,
etc., but we do arrive at the same answer in each case.

> 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.

Let's look at the example given in other posts:

   add_month(add_month(d, 1), 1)

If such code -- however those two calls actually come about --
occurs when d is late in January, it only advances by 56 days,
well less than 1/6 of a year, with your interpretation.  With
mine, it would advance by 61 days, which is very nearly 1/6 of a
year.  Thus, mine gives more predictable results when considering
a "month" to be approximately 1/12 of a year, which I do.

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