Horton

Thread

Commits

  1. Avoid choosing "localtime" or "posixrules" as TimeZone during initdb.

  1. "localtime" value in TimeZone

    Shay Rojansky <roji@roji.org> — 2019-07-24T15:19:40Z

    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

  2. Re: "localtime" value in TimeZone

    Tom Lane <tgl@sss.pgh.pa.us> — 2019-07-24T15:50:12Z

    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
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

  3. Re: "localtime" value in TimeZone

    Shay Rojansky <roji@roji.org> — 2019-07-25T16:51:25Z

    > 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"?

  4. Re: "localtime" value in TimeZone

    Tom Lane <tgl@sss.pgh.pa.us> — 2019-07-25T20:37:36Z

    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