From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Shay Rojansky <roji(at)roji(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: "localtime" value in TimeZone |
Date: | 2019-07-24 15:50:12 |
Message-ID: | 27164.1563983412@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Shay Rojansky <roji(at)roji(dot)org> writes:
> In (certain) out-of-the-box PostgreSQL installations, the timezone GUC is
> set to "localtime", which seems to mean to query the OS for the value.
> Unless I'm mistaken, the issue with this is that it doesn't allow clients
> inspecting the TimeZone GUC to actually know what timezone the server is
> in, making the GUC largely useless (and creates friction as the GUC can't
> be expected to always contain valid IANA/Olson values). It would be more
> useful if PostgreSQL exposed the actual timezone provided by the OS.
> Does this make sense?
Yeah, this is something that some tzdb packagers do --- they put a
"localtime" file into /usr/share/zoneinfo that is a symlink or hard link
to the active zone file, and then initdb tends to seize on that as being
the shortest available spelling of the active zone.
I opined in
https://www.postgresql.org/message-id/27991.1560984458@sss.pgh.pa.us
that we should avoid choosing "localtime", but that thread seems
stalled on larger disagreements about how complicated we want that
mechanism to be.
> As a side note, there doesn't seem to be any specific documentation on the
> special "localtime" value of this GUC
That's because it's nonstandard and platform-specific. It's also
not special from our standpoint --- it's jsut another zone file.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2019-07-24 17:30:09 | Re: GiST VACUUM |
Previous Message | Alvaro Herrera | 2019-07-24 15:23:30 | Re: [PATCH] minor bugfix for pg_basebackup (9.6 ~ ) |