Re: Extract epoch from Interval weird behavior

From: Aleksander Alekseev <aleksander(at)timescale(dot)com>
To: Joseph Koshakow <koshy44(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Extract epoch from Interval weird behavior
Date: 2022-02-24 09:47:36
Message-ID: CAJ7c6TMxMus4FvpzkwsROT7EwG3tk_Mn7yfPT-93h7PeSLWYzQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Joseph,

> > Is this truncation on purpose? It seems like
> > EXTRACT is not accounting for leap years in
> > it's calculation.

Extracting an epoch from an interval is quite a strange case since
intervals are not connected to any specific dates.

For instance:

select extract('epoch' from interval '1 month')

.. returns 2592000 = 30*24*60*60. But what if the month is February? Should
we account for the different number of days for intervals like 6 months or
24 months?

Also, leap years don't just happen every 4 years. Here is the actual logic:

bool is_leap_year(int Y) {
if(Y % 400 == 0) return true;
else if(Y % 100 == 0) return false;
else if(Y % 4 == 0) return true;
else return false;
}

And what about leap seconds?

All in all, I don't think that the benefit of the proposed change outweighs
the fact that it will break the previous behavior for the users who may
rely on it. I suggest keeping it simple, i.e. the way it is now. What I
think we could do instead is explicitly document this behavior in [1].

[1]: https://www.postgresql.org/docs/current/functions-datetime.html

--
Best regards,
Aleksander Alekseev

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-02-24 09:48:41 Re: Design of pg_stat_subscription_workers vs pgstats
Previous Message Tatsuo Ishii 2022-02-24 09:38:57 Re: Typo in pgbench messages.