From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl>, John Naylor <johncnaylorls(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: date_trunc function in interval version |
Date: | 2024-02-18 00:29:08 |
Message-ID: | 31d83de5-66f7-4f04-bcde-5798b75d4105@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
In particular, isn't part of the problem that date_bin() is defined only
for timestamp and not for timestamptz? Also, date_trunc() allows to
specify a timezone, but date_bin() does not.
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.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-02-18 00:47:38 | Re: Add pg_basetype() function to obtain a DOMAIN base type |
Previous Message | Tomas Vondra | 2024-02-17 23:29:45 | Re: Add pg_basetype() function to obtain a DOMAIN base type |