Re: mark the timestamptz variant of date_bin() as stable

> On Wed, Sep 1, 2021 at 3:25 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > 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.
>
> Attached is a draft doc patch using the above examples. Is there anything
else that would be useful to mention?

Any thoughts on the doc patch?

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