Re: Comments on earlier age() post.

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!

In response to

Responses

Browse pgsql-general by date

  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