Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL);

Francisco Olarte <folarte@peoplecall.com>

From: Francisco Olarte <folarte@peoplecall.com>
To: Michael Bondarenko <work.michael.2956@gmail.com>
Cc: jian he <jian.universality@gmail.com>, pgsql-bugs@lists.postgresql.org, dgrowleyml@gmail.com
Date: 2024-02-17T15:12:15Z
Lists: pgsql-bugs, pgsql-hackers
On Sat, 17 Feb 2024 at 09:01, Michael Bondarenko
<work.michael.2956@gmail.com> wrote:
> When testing I stumbled upon that too, but I thought no calculation was happening in the interval field. However, it's different with the days and months etc. It seems no calculation for day and month and more:
...
> But calculation is present for hour, and minutes and seconds (90061 sec is 1 day 1 hour 1 minute 1 second):

No, intervals have seconds, days and months. This is because not all
days have 24 hours, due to DST they can have 23 or 25, or even more
extreme values if some country decides to change its time zone
definition. And not all months have 30 days, so 90061 is 0 months, 0
days, 25 hours, 1 minute, 1 second ( IIRC leap second are not handled
).

It is done that way so when you add one day across a dst jump you get
the same hour on the next day, and when you add one month you get the
same day in the next month independent of how many days the month has.
This is great for things like "schedule a meeting one month and one
week from now", but it bites you sometimes, like when you need a
duration to bill for a long event like a phone call, where I always
end up extracting epoch and substracting them.

Francisco Olarte.



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix extraction of week and quarter fields from intervals.

  2. Doc: improve explanation of type interval, especially extract().