From: Jeff Garland (jeff_at_[hidden])
Date: 2004-04-24 08:35:49
On Fri, 23 Apr 2004 23:22:34 -0400, Daryle Walker wrote
> [NOTE: I haven't worked on this library; I'm just going by the posts
> I see here.]
> For this increment/decrement by a month problem, is there any way to
> store a date with only a month resolution? Nothing smaller will be
> stored, so day crossovers won't be a problem.
I think what you mean is a 'duration' with month resolution. Ala
months m3 = m2 + m1;
This can be done, but the issue is that to work with the date timepoint
calculation is done at single day resolution. And there isn't a fixed number
of days in a month, so you CANNOT say:
days dd(28) == months(1); //proposition 1
Similarly the following is NOT true:
days dd(365) == years(1); //proposition 2
Conversly, you can always say this:
days dd(28) == weeks(4);
So the problem is while a week is a fixed length that is well known to be 7
days, a month and year are not. The length of a month and year depends on the
context of the date. So people want the following sort of behavior:
date d1 += months(12); //if d1 is a leap year add 366 days instead of 365
Unfortunately, as soon as you start accepting these sorts of adjustments you
lose the mathmatical properties that you might expect:
date d1 += months(1);
date d2 = d1 - months(1);
d2 == d1 //Sorry, not always true...
If instead you are willing to accept proposition 1 and 2 above then this is
> Wouldn't something
> similar have/already-had been done when skipping days but ignoring
> the exact hour?
No, because a day is a fixed length duration while a month isn't -- see above.
>(Or does every date-time object work at the
> fractional-second level? If so, maybe that's what needs fixing.)
No, boost::gregorian::date has a resolution of 1 day -- it can't represent
hours, minutes, etc...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk