From: | "Mitch Vincent" <mitch(at)venux(dot)net> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Comments on earlier age() post. |
Date: | 2000-10-12 16:45:49 |
Message-ID: | 00a501c0346b$e06cddf0$0200000a@doot |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> 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!
From | Date | Subject | |
---|---|---|---|
Next Message | Adam Lang | 2000-10-12 16:46:18 | Re: postgresql 7.1 |
Previous Message | Bruce Momjian | 2000-10-12 16:41:35 | Re: postgresql 7.1 |