On Tue, May 8, 2018 at 4:48 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Really the only thing here that jumps out as being unduly expensive for
> what it's doing is select_default_timezone. That is, and always has been,
> a brute-force algorithm; I wonder if there's a way to do better? We can
> probably guess that every non-Windows platform is using the IANA timezone
> data these days. If there were some way to extract the name of the active
> timezone setting directly, we wouldn't have to try to reverse-engineer it.
> But I don't know of any portable way :-(
Who says we need a portable way? If we had something that worked on
Linux and macOS, it would cover most developer environments. I wonder
if readlink("/etc/localtime", buf, sz) might be a viable approach.
You could, at least, try any time zone you can derive that way first,
before you try any others.
Also, how about having a --timezone option for initdb? Then you could
determine the time zone just once and pass it down to subsequent
initdb invocations. Or just hardcode the regression tests to use some
fixed time zone, like Antarctica/Troll. :-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
