Re: date_trunc function in interval version

From: Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: John Naylor <johncnaylorls(at)gmail(dot)com>, 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-03-04 10:03:14
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tomas Vondra wrote on 18.02.2024 01:29:
> 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?
Apparently the functionality is identical to date_bin.
When I saw date_bin in the documentation, I thought it solved all my
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.

> 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

Attachment Content-Type Size
date_trunc_interval_version-v2.patch text/plain 24.4 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2024-03-04 10:39:18 Re: PostgreSQL Contributors Updates
Previous Message Amit Kapila 2024-03-04 09:51:52 Re: Synchronizing slots from primary to standby