Re: truncating timestamps on arbitrary intervals

Justin Pryzby <pryzby@telsasoft.com>

From: Justin Pryzby <pryzby@telsasoft.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: John Naylor <john.naylor@enterprisedb.com>, pgsql-hackers@postgresql.org
Date: 2021-04-22T09:16:04Z
Lists: pgsql-hackers
On Fri, Apr 09, 2021 at 10:02:47PM +0200, Peter Eisentraut wrote:
> On 30.03.21 18:50, John Naylor wrote:
> > On Sat, Mar 27, 2021 at 1:06 PM Justin Pryzby wrote:
> >  >
> >  > The current docs seem to be missing a "synopsis", like
> >  >
> >  > +<synopsis>
> >  > +date_trunc(<replaceable>stride</replaceable>, <replaceable>timestamp</replaceable>, <replaceable>origin</replaceable>)
> >  > +</synopsis>
> > 
> > The attached
> > - adds a synopsis
> > - adds a bit more description to the parameters similar to those in
> > date_trunc
> > - documents that negative intervals are treated the same as positive ones
> > 
> > Note on the last point: This just falls out of the math, so was not
> > deliberate, but it seems fine to me. We could ban negative intervals,
> > but that would possibly just inconvenience some people unnecessarily. We
> > could also treat negative strides differently somehow, but I don't
> > immediately see a useful and/or intuitive change in behavior to come of
> > that.
> 
> committed

It looks like we all missed that I misspelled "date_bin" as
"date_trunc"...sorry.  I will include this with my next round of doc review, in
case you don't want to make a separate commit for it.

https://www.postgresql.org/docs/devel/functions-datetime.html#FUNCTIONS-DATETIME-BIN

Commits

  1. Disallow negative strides in date_bin()

  2. Improve behavior of date_bin with origin in the future

  3. doc: Additional documentation for date_bin

  4. Add date_bin function