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

From: Marek Läll <lall(dot)marek(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17240: <timestamptz> at time zone ... ; wrong result
Date: 2021-10-25 07:35:34
Message-ID: CADDPzFTa7ipw157Ep7rx2a=grWN71xsfXA4-=X31LzGEuv4_fA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi!

Thank you for your response, Tom.

I have multiple questions/comments but let's start one-by-one.

POSIX string (syntax) is defined as:
--> stdoffset[dst[offset][,start-date[/time],end-date[/time]]]

The std string specifies the name of the time zone.
It must be three or more characters long and must not contain a leading
colon, embedded digits, commas, nor plus and minus signs.
There is no space character separating the time zone name from the offset,
so these restrictions are necessary to parse the specification correctly.

For "Pacific Time (Canada & US)" aka "America/Los_Angeles" the POSIX
version looks like: "PST8PDT,M3.2.0,M11.1.0"

Here are results of experiment:

$ export TZ="PST8PDT,M3.2.0,M11.1.0" ; date --iso-8601=seconds
2021-10-24T12:10:51-07:00 <-- CORRECT

$ export TZ="UTC" ; date --iso-8601=seconds
2021-10-24T19:11:32+00:00 <-- CORRECT

$ export TZ="-07:00" ; date --iso-8601=seconds
2021-10-24T19:11:42+00:00 <-- TZ is IGNORED, because "-07:00" is not
valid POSIX syntax

$ export TZ="-0700" ; date --iso-8601=seconds
2021-10-24T19:11:46+00:00 <-- TZ is IGNORED, because "-0700" is not valid
POSIX syntax

$ export TZ="-07" ; date --iso-8601=seconds
2021-10-24T19:55:08+00:00 <-- TZ is IGNORED, because "-07" is not valid
POSIX syntax

$ export TZ="-07RandomMeaninglessString" ; date --iso-8601=seconds
2021-10-24T19:14:55+00:00 <-- TZ is IGNORED, because
"-07RandomMeaninglessString" is not valid POSIX syntax

$ uname -a
Linux 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 GNU/Linux

Back to POSTGRES case:
> postgres> select timestamptz'2021-10-01 07:00:00 UTC' at time zone
'-07:00' as revers_res2;
> 2021-10-01 14:00:00

The value '-07:00' is not a valid POSIX value but ... Postgres performs the
following (as concept):
1) first: reads in the string '-07:00'
2) then: ignores the fact that string '-07:00' is invalid POSIX value
3) then: decides to follow "POSIX sign convention" rules (still ignoring
previous fact)
4) and then: applies "POSIX sign convention" rules using invalid POSIX
value as input?

Regards
Marek

Kontakt Tom Lane (<tgl(at)sss(dot)pgh(dot)pa(dot)us>) kirjutas kuupäeval N, 21. oktoober
2021 kell 16:41:

> 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 Andrey Borodin 2021-10-25 08:30:32 Re: conchuela timeouts since 2021-10-09 system upgrade
Previous Message K. R. 2021-10-25 07:23:26 Re: BUG #17245: Index corruption involving deduplicated entries