Re: Comments on earlier age() post.
От | Mitch Vincent |
---|---|
Тема | Re: Comments on earlier age() post. |
Дата | |
Msg-id | 00a501c0346b$e06cddf0$0200000a@doot обсуждение исходный текст |
Ответ на | Comments on earlier age() post. ("Mitch Vincent" <mitch@venux.net>) |
Ответы |
Re[2]: Comments on earlier age() post.
|
Список | 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!
В списке pgsql-general по дате отправления: