| commit | a3021aafcecbc5225bf99f235db4130546d543c1 | |
| author | Tom Lane <tgl@sss.pgh.pa.us> | |
| Sun, 21 Apr 2024 17:46:20 +0000 (21 13:46 -0400) | ||
| committer | Tom Lane <tgl@sss.pgh.pa.us> | |
| Sun, 21 Apr 2024 17:46:20 +0000 (21 13:46 -0400) | ||
| tree | e991964f30c74de7b3cb717d5b31f4fa811408e9 | treesnapshot (tar.gz zip) |
| parent | f4fdc24aa35c2268f519905a3a66658ebd55a466 | commitdiff |
Make postgres_fdw request remote time zone 'GMT' not 'UTC'.
This should have the same results for all practical purposes.
The advantage of selecting 'GMT' is that it's guaranteed to work
even when the remote system's timezone database is missing
entries, because pg_tzset() hard-wires handling of that,
at least in 9.2 and later.
(It seems like it would be a good idea to similarly hard-wire
correct handling of 'UTC', but that'll be a little more invasive
than I want to consider back-patching. Leave that for another
day when we're not in feature freeze.)
Per trouble report from Adnan Dautovic. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/465248.1712211585@sss.pgh.pa.us
This should have the same results for all practical purposes.
The advantage of selecting 'GMT' is that it's guaranteed to work
even when the remote system's timezone database is missing
entries, because pg_tzset() hard-wires handling of that,
at least in 9.2 and later.
(It seems like it would be a good idea to similarly hard-wire
correct handling of 'UTC', but that'll be a little more invasive
than I want to consider back-patching. Leave that for another
day when we're not in feature freeze.)
Per trouble report from Adnan Dautovic. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/465248.1712211585@sss.pgh.pa.us
| contrib/postgres_fdw/connection.c | diffblobblamehistory |