| 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: | Whole Thread | Raw Message | 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 |