Re: BUG #17240: <timestamptz> at time zone ... ; wrong result

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: marek(dot)lall(at)eesti(dot)ee
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17240: <timestamptz> at time zone ... ; wrong result
Date: 2021-10-21 13:41:00
Message-ID: 2402843.1634823660@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> # select now()
> , now() at time zone 'America/Los_Angeles' as correct
> , now() at time zone '-07:00:00' as wrong;

Unfortunately, the pure-numeric syntax for time zone names follows the
POSIX sign convention, which is opposite to the ISO convention used
in pg_timezone_names.utc_offset (and in most other places in Postgres).
So "at time zone '+07:00:00'" is what you needed to write to duplicate
the 'America/Los_Angeles' result. See

https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-TIMEZONES

Now, if you'd done this:

select ... now() at time zone interval '-07:00:00' as fine

you'd have gotten the ISO sign interpretation. But an undecorated
literal string defaults to being of type text, meaning you get
the time-zone-name logic path.

The great thing about standards is there are so many to choose from :-(

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2021-10-21 17:34:25 BUG #17242: Postgis 2.5 fails to install and fails to load due to broken gdal32-libs RPM
Previous Message PG Bug reporting form 2021-10-21 13:25:16 BUG #17241: llvm::install_bad_alloc_error_handler error