From: David Abrahams <dave@boost-consulting.com>
"Jeff Garland" <jeff@crystalclearsoftware.com> 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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;