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.
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() |