BUG #16123: DST not respected for America/Sao_Paulo in `timestamp` function
The following bug has been logged on the website:
Bug reference: 16123
Logged by: Thushara Wijeratna
Email address: thushw@gmail.com
PostgreSQL version: 11.5
Operating system: MacOS (Mojave)
Description:
maestro_development=# select timestamp with time zone '2019-12-01T02:00:00Z'
at time zone 'America/Sao_Paulo';
timezone
---------------------
2019-11-30 23:00:00
(1 row)
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.
On Mon, Nov 18, 2019 at 6:38 PM PG Bug reporting form
<noreply@postgresql.org> wrote:
The following bug has been logged on the website:
Bug reference: 16123
Logged by: Thushara Wijeratna
Email address: thushw@gmail.com
PostgreSQL version: 11.5
Operating system: MacOS (Mojave)
Description:maestro_development=# select timestamp with time zone '2019-12-01T02:00:00Z'
at time zone 'America/Sao_Paulo';
timezone
---------------------
2019-11-30 23:00:00
(1 row)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?
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
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:
Show quoted text
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