Re: "localtime" value in TimeZone
Shay Rojansky 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
Re: "localtime" value in TimeZone
> 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"?
Re: "localtime" value in TimeZone
Shay Rojansky 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.1560984...@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
"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
