Re: Inconsistent 'at time zone' conversion

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Umut TEKİN <umuttechin(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Inconsistent 'at time zone' conversion
Date: 2023-02-19 23:46:03
Message-ID: CAKFQuwa-VxQdeXK=KOQSTdk9QMwo6dDOoRH3Cv97mc9V-5=H9Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sun, Feb 19, 2023 at 4:10 PM Umut TEKİN <umuttechin(at)gmail(dot)com> wrote:

> I think I found a bug about time zones.
>

Nope, the observed behavior is documented.

1. select now();
> 2023-02-19 21:52:12.537849+00
>
> 2. select now()::timestamp with time zone at time zone 'America/Denver';
> 2023-02-19 14:52:12.5383
>
> 3. select now()::timestamp with time zone at time zone 'UTC-7';
> 2023-02-20 04:52:12.538804
>
> In America/Denver, UTC-7 is using as time zone that is why 1st and 2nd
> queries confirm each other, but 3rd query completely disapproves first two
> queries. Instead of '2023-02-19 14:52:12.538804', it shows '2023-02-20
> 04:52:12.538804'.
>

Unfortunately the actual +/- direction convention in use here is not the
one you are expecting. It is defined to be the reverse of what you've
said, and so you get the observed behavior.

https://www.postgresql.org/docs/current/datetime-posix-timezone-specs.html
David J.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-02-19 23:49:47 Re: Inconsistent 'at time zone' conversion
Previous Message Tom Lane 2023-02-19 23:40:59 Re: BUG #17795: Erroneous parsing of floating-poing components in DecodeISO8601Interval()