> This is more Thomas' bailiwick than mine, but it seems to me that these
> operations are inherently rather ill-defined. Consider: counting
> forward from Oct 10 to Dec 3, one would naturally call the interval
> "1 month + 23 days" (1 month takes you to Nov 10, from which it's
> 23 days to Dec 3, no?). But counting backwards from Dec 3 to Oct 10
> looks like "1 month + 22 days" (1 month takes you to Nov 3, from which
> it's 22 days back to Oct 12). The trouble is that Oct and Nov have
> different numbers of days, so you get different answers depending on
> what your referent for "1 month" is.
I see what you mean..
> There may indeed be a bug here --- it bothers me that counting on my
> fingers gives 22/23 days where the system says 23/24. But I'm not
> sure there's anything wrong with the fact that (A-B)+B != A, given
> the way type interval is defined.
Indeed, I'm not so sure now that I think about it either -- still, I need to
find the number of days (or amount of time I should say) I need to add to A
to get to B. I wanted to do it in the database becuae I had hoped that
timezones, leap years and anything else that might require more calculations
would be taken into account. I'm experimenting with a few other ways of
doing this but I'm running into some more innaccuracies..
> Maybe we need to offer a different kind of interval that avoids the
> symbolic "month" rigmarole and just counts honest-to-god seconds.
Certainly an idea!
Thanks Tom!
