From: | Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl> |
---|---|
To: | 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: | 2023-12-23 22:45:23 |
Message-ID: | 21773b3e-4ec7-c6a0-e954-ee031ddcdea0@sztoch.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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...
John Naylor wrote on 23.12.2023 01:32:
> On Sat, Dec 23, 2023 at 5:26 AM Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl> wrote:
>> In my opinion date_trunc is very good name.
>> Truncated data is timestamp type, not interval.
>> First parameter has same meaning in original date_trunc and in my new version.
>> New version provides only more granularity.
> I haven't looked at the patch, but your description sounds awfully
> close to date_bin(), which already takes an arbitrary interval.
--
Przemysław Sztoch | Mobile +48 509 99 00 66
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-12-23 22:48:11 | Re: Are operations on real values IMMUTABLE or STABLE? |
Previous Message | Nathan Bossart | 2023-12-23 21:51:47 | Re: trying again to get incremental backup |