Re: mark the timestamptz variant of date_bin() as stable - Mailing list pgsql-hackers

From John Naylor
Subject Re: mark the timestamptz variant of date_bin() as stable
Date
Msg-id CAFBsxsEicJ7JPO2qp8YBeDtHJ208yWZKD5j4OyRAF=BT2gd4Zw@mail.gmail.com
Whole thread Raw
In response to Re: mark the timestamptz variant of date_bin() as stable  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On Wed, Sep 1, 2021 at 3:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> John Naylor <john.naylor@enterprisedb.com> writes:
> > On Wed, Sep 1, 2021 at 2:44 PM Tom Lane <tgl@sss.pgh.pa.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.

Having heard no votes on changing this behavior (and it would be a bit of work), I'll start on a documentation patch. And I'll go ahead and re-mark the function as immutable tomorrow barring objections.

--
John Naylor
EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Dipesh Pandit
Date:
Subject: Re: .ready and .done files considered harmful
Next
From: Robert Haas
Date:
Subject: Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints