Re: extract('epoch' from age()) returning wrong number of seconds

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Nelson <peter(dot)nelson(at)code42(dot)com>
Cc: "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: extract('epoch' from age()) returning wrong number of seconds
Date: 2014-07-30 18:00:23
Message-ID: 2110.1406743223@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Peter Nelson <peter(dot)nelson(at)code42(dot)com> writes:
> The forth column in this query is returning the wrong value.

No it isn't.

The underlying result of the age() function is

# select age (('2013-12-31'::date) , ('2013-12-31'::date - '5270400 seconds'::interval));
age
--------
2 mons
(1 row)

which is the desired result in this case: it's two months from 2013-10-31
to 2013-12-31. Then extract(epoch from interval) arbitrarily assumes that
a "month" equals 2592000 seconds (30 days), which isn't the greatest
thing, but without any context there's no way for it to do much better.

For the result that you're after, timestamp subtraction is the way
to get it:

select (('2013-12-31'::date) - ('2013-12-31'::date - '5270400 seconds'::interval));
?column?
----------
61 days
(1 row)

Bottom line: age() is not meant to exactly reproduce timestamp
subtraction, and it's not a bug that it doesn't. It's *supposed* to give
you symbolic results like "2 months" rather than "61 days", or "1 year"
rather than "365 days" (or sometimes "366 days"). In the same vein,
it tries to abstract away from daylight-savings-time changes ...

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message vipivoxa 2014-07-30 18:57:43 BUG #11093: login with cyrilic input language make pgAdmin to blow out instead of the wrong password message.
Previous Message Bruce Momjian 2014-07-30 17:53:25 Re: BUG #10823: Better REINDEX syntax.