Re: BUG #16123: DST not respected for America/Sao_Paulo in`timestamp` function

Поиск
Список
Период
Сортировка
От Thushara Wijeratna
Тема Re: BUG #16123: DST not respected for America/Sao_Paulo in`timestamp` function
Дата
Msg-id CACNZz6yn5Dtg4BswZK8CvLknwGZuTf=zTnGVWFgg0emB9KZS5g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #16123: DST not respected for America/Sao_Paulo in `timestamp` function  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Thanks Tom, I now realize the bug was actually in an out-dated tzinfo-data ruby gem I was using.

I upgraded and ruby is now in sync with pg: https://rubygems.org/gems/tzinfo-data

best,
thushara

On Mon, Nov 18, 2019 at 6:41 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thomas Munro <thomas.munro@gmail.com> writes:
> On Mon, Nov 18, 2019 at 6:38 PM PG Bug reporting form
> <noreply@postgresql.org> wrote:
>> From Nov 3, America/Sao_Paulo should be offset only 2 hours from UTC due to
>> DTS. I would expect the timestamp to be December 1st midnight.

> I was going to reply with some details about how to find out whether
> you're using timezone data files from PostgreSQL or macOS, and how to
> make sure they're up-to-date in both cases, but now I see that my
> computer (which has up-to-date tzdata) agrees with yours, and
> Wikipedia claims that DST was cancelled this year by presidential
> decree.  Why do you think it's wrong?

Indeed, the IANA timezone folks changed their entry in tzdata 2019b,
on the strength of this:

https://mm.icann.org/pipermail/tz/2019-April/027848.html

and other nearby threads in that list archive.  2019b was released
2019-07-02, so any machine with reasonably up-to-date data should
know about this.  In the case of Postgres, we absorbed that change
in the August minor releases.

                        regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Gmail
Дата:
Сообщение: Re: BUG #16119: pg_dump omits columns specification for matviews
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: BUG #16125: Crash of PostgreSQL's wal sender during logicalreplication