| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org | 
| Subject: | Re: postgres_fdw fails because GMT != UTC | 
| Date: | 2024-04-04 06:48:57 | 
| Message-ID: | c6d1a1f8900965b915b2ff6a6eb8d0413a6ae67e.camel@cybertec.at | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Thu, 2024-04-04 at 02:19 -0400, Tom Lane wrote:
> > ERROR:  invalid value for parameter "TimeZone": "UTC"
> 
> I am not quite clear on how broken an installation needs to be to
> reject "UTC" as a time zone setting, except that the breakage cannot
> be subtle.  However, I notice that our code in pgtz.c and other
> places treats "GMT" as a hard-wired special case ... but not "UTC".
> I wonder if we ought to modify those places to force "UTC" down the
> same hard-wired paths.  If we acted like that, this would have worked
> no matter how misconfigured the installation was.
> 
> An alternative answer could be to change postgres_fdw to send "GMT"
> not "UTC".  That's ugly from a standards-compliance viewpoint, but
> it would fix this problem even with a non-updated remote server,
> and I think postgres_fdw is generally intended to work with even
> very old remote servers.
> 
> Or we could do both.
I think the first is desirable for reasons of general sanity, and the
second for best compatibility with old versions.
So I vote for "both".
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2024-04-04 06:49:46 | Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~? | 
| Previous Message | jian he | 2024-04-04 06:41:48 | Re: remaining sql/json patches |