From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
Cc: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: mark the timestamptz variant of date_bin() as stable |
Date: | 2021-09-01 19:25:55 |
Message-ID: | 2117318.1630524355@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
John Naylor <john(dot)naylor(at)enterprisedb(dot)com> writes:
> On Wed, Sep 1, 2021 at 2:44 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I see that these two answers are both exactly multiples of 24 hours away
>> from the given origin. But if I'm binning on the basis of "days" or
>> larger units, I would sort of expect to get local midnight, and I'm not
>> getting that once I cross a DST boundary.
> Hmm, that's seems like a reasonable expectation. I can get local midnight
> if I recast to timestamp:
> # select date_bin('1 day', '2021-11-10 00:00 +00'::timestamptz::timestamp,
> '2021-09-01 00:00 -04'::timestamptz::timestamp);
> date_bin
> ---------------------
> 2021-11-09 00:00:00
> (1 row)
Yeah, and then back to timestamptz if that's what you really need :-(
> It's a bit unintuitive, though.
Agreed. If we keep it like this, adding some documentation around
the point would be a good idea I think.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2021-09-01 19:38:16 | Re: PoC/WIP: Extended statistics on expressions |
Previous Message | John Naylor | 2021-09-01 19:18:54 | Re: mark the timestamptz variant of date_bin() as stable |