Re: date_trunc function in interval version
От | Przemysław Sztoch |
---|---|
Тема | Re: date_trunc function in interval version |
Дата | |
Msg-id | 48c25521-6386-b2cc-5f1e-b1e08034d81f@sztoch.pl обсуждение исходный текст |
Ответ на | Re: date_trunc function in interval version (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: date_trunc function in interval version
|
Список | pgsql-hackers |
Tomas Vondra wrote on 18.02.2024 01:29:
When I saw date_bin in the documentation, I thought it solved all my problems.
Unfortunately, DST problems have many corner cases.
I tried to change date_bin several times, but unfortunately in some cases it would start working differently than before.
Apparently the functionality is identical to date_bin.Hi, Please don't too-post on this list. The custom is to bottom-post or reply inline, and it's much easier to follow such replies. On 12/23/23 23:45, Przemysław Sztoch wrote:date_bin has big problem with DST. In example, if you put origin in winter zone, then generated bin will be incorrect for summer input date. date_trunc is resistant for this problem. My version of date_trunc is additionally more flexible, you can select more granular interval, 12h, 8h, 6h, 15min, 10 min etc...I'm not very familiar with date_bin(), but is this issue inherent or could we maybe fix date_bin() to handle DST better?
When I saw date_bin in the documentation, I thought it solved all my problems.
Unfortunately, DST problems have many corner cases.
I tried to change date_bin several times, but unfortunately in some cases it would start working differently than before.
Updated.In any case, the patch needs to add the new stuff to the SGML docs (to doc/src/sgml/func.sgml), which now documents the date_trunc(text,...) variant only.
--
Przemysław Sztoch | Mobile +48 509 99 00 66
Przemysław Sztoch | Mobile +48 509 99 00 66
Вложения
В списке pgsql-hackers по дате отправления: