Re: date_trunc function in interval version

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

In response to

Responses

Browse pgsql-hackers by date

  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