Re: mark the timestamptz variant of date_bin() as stable
От | Tom Lane |
---|---|
Тема | Re: mark the timestamptz variant of date_bin() as stable |
Дата | |
Msg-id | 2117318.1630524355@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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
Re: mark the timestamptz variant of date_bin() as stable |
Список | pgsql-hackers |
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. regards, tom lane
В списке pgsql-hackers по дате отправления: