Thread: BUG #16123: DST not respected for America/Sao_Paulo in `timestamp` function
BUG #16123: DST not respected for America/Sao_Paulo in `timestamp` function
From
PG Bug reporting form
Date:
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.
https://www.travelmath.com/time-zone/America/Sao_Paulo
Re: BUG #16123: DST not respected for America/Sao_Paulo in`timestamp` function
From
Thomas Munro
Date:
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. > > https://www.travelmath.com/time-zone/America/Sao_Paulo 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? https://en.wikipedia.org/wiki/Time_in_Brazil
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
Re: BUG #16123: DST not respected for America/Sao_Paulo in`timestamp` function
From
Thushara Wijeratna
Date:
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