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

Поиск
Список
Период
Сортировка
От Aleksander Alekseev
Тема Re: mark the timestamptz variant of date_bin() as stable
Дата
Msg-id CAJ7c6TMV=g9jVOs5_EqzLOjOwnK4AFexWF3f+_pD7HypbHQuSQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: mark the timestamptz variant of date_bin() as stable  (John Naylor <john.naylor@enterprisedb.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Sergey Shinderuk
Дата:
Сообщение: Re: Compile fail on macos big sur
Следующее
От: "Drouvot, Bertrand"
Дата:
Сообщение: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns