Thank you very much for your reply, i'am clear now.
Here is an example, which seems to be a problem of parsing, if format string with FF and TZH:TZM, but the datetime string without fractional seconds will cause parsing misalignment，example：
postgres=# set timezone='-04:00';
SET
postgres=#
/* datetime string with fractional second */
postgres=# select to_timestamp('2021-6-9 10:30:30.369 +04:00', 'YYYY-MM-DD HH24:MI:SS.FF3 TZH:TZM');
to_timestamp
----------------------------
2021-06-09 10:30:30.369+04
(1 row)
postgres=#
/* datetime string without fractional second */
postgres=# select to_timestamp('2021-6-9 10:30:30 +04:00', 'YYYY-MM-DD HH24:MI:SS.FF3 TZH:TZM');
to_timestamp
---------------------------
2021-06-09 14:30:30.04+04
(1 row)
postgres=#
At 2021-06-09 02:02:50, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>甄明洋 <zhenmingyang@yeah.net> writes:
>> /* timezone string with space */
>> postgres=# set timezone=' +04:00 ';
>> SET
>> postgres=# select now();
>> now
>> -------------------------------
>> 2021-06-08 05:14:36.486693-03
>> (1 row)
>
>What is happening here is that the setting is being interpreted
>much like 'X+04:00Y'. That is, it's taken as a POSIX timezone
>specifier with standard-time abbreviation being ' ', daylight-
>savings abbreviation also being ' ', and the daylight-savings
>offset and transition rules all being defaulted. Your example
>without any spaces is recognized as a POSIX timezone spec
>with no DST part, so that's why it behaves differently.
>
>There's certainly room to quibble about whether a single space
>ought to be considered a valid zone abbreviation. However,
>this behavior comes directly from the IANA tzcode library,
>so I'm hesitant to change it.
>
> regards, tom lane