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

From Aleksander Alekseev
Subject Re: mark the timestamptz variant of date_bin() as stable
Date
Msg-id CAJ7c6TMV=g9jVOs5_EqzLOjOwnK4AFexWF3f+_pD7HypbHQuSQ@mail.gmail.com
Whole thread Raw
In response to Re: mark the timestamptz variant of date_bin() as stable  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: mark the timestamptz variant of date_bin() as stable  (Aleksander Alekseev <aleksander@timescale.com>)
Re: mark the timestamptz variant of date_bin() as stable  (John Naylor <john.naylor@enterprisedb.com>)
List pgsql-hackers
Hi John,

> Any thoughts on the doc patch?

It so happened that I implemented a similar feature in TimescaleDB [1].

I discovered that it's difficult from both developer's and user's
perspectives to think about the behavior of the function in the
context of given TZ and its complicated rules, as you are trying to do
in the doc patch. So what we did instead is saying: for timestamptz
the function works as if it was timestamp. E.g. time_bucket_ng("3
month", "2021 Oct 03 12:34:56 TZ") = "2021 Jan 01 00:00:00 TZ" no
matter what TZ it is and what rules (DST, corrections, etc) it has. It
seems to be not only logical and easy to understand, but also easy to
implement [2].

Do you think it would be possible to adopt a similar approach in
respect of documenting for date_bin()? To be honest, I didn't try to
figure out what is the actual implementation of date_bin() for TZ
case.

[1]: https://docs.timescale.com/api/latest/hyperfunctions/time_bucket_ng/
[2]: https://github.com/timescale/timescaledb/blob/master/src/time_bucket.c#L470

-- 
Best regards,
Aleksander Alekseev



pgsql-hackers by date:

Previous
From: Sergey Shinderuk
Date:
Subject: Re: Compile fail on macos big sur
Next
From: "Drouvot, Bertrand"
Date:
Subject: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns