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: | Raw Message | Whole Thread | 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 |