"localtime" value in TimeZone
Greetings everyone.
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?
As a side note, there doesn't seem to be any specific documentation on the
special "localtime" value of this GUC (e.g.
https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-TIMEZONES
).
Shay
Shay Rojansky <roji@roji.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
/messages/by-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
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 see, I wasn't aware that this was a distribution-level mechanism - I
understand the situation better now.
I followed the conversations you linked to, and disagreements seem to be
mostly about other aspects of timezone selection. Does it make sense to
have a limited, restricted conversation specifically about avoiding
"localtime"?
Shay Rojansky <roji@roji.org> writes:
I followed the conversations you linked to, and disagreements seem to be
mostly about other aspects of timezone selection. Does it make sense to
have a limited, restricted conversation specifically about avoiding
"localtime"?
I've tried to kick-start the other thread...
regards, tom lane