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
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. |