Re: The timezone oddities

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>
Cc: Rob Sargent <robjsargent(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: The timezone oddities
Date: 2014-02-04 22:44:38
Message-ID: 31574.1391553878@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> writes:
> On 02/04/2014 12:31 PM, Rob Sargent wrote:
>> Perhaps building from source does make a guess at TZ. I am not residing
>> in the Navaho national territory, but is that just Mountain time?

> Yes:
> http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
> The reason for specificity is that the Navajo Nation observes DST, while
> the rest of Arizona does not.

Not quite. The zoneinfo database has a number of names for Mountain Time
with DST, eg America/Denver. A quick look says that "Navajo" is just an
alias for that one, so no probe of the system's timezone behavior is going
to be able to tell the difference. IIRC, given two zone names that both
match the system's behavior equally well, initdb chooses the shorter one.
That heuristic produces good results in many places, but not so much here.

Note that this is exactly the same choice of zone you'd have gotten from
pre-9.2 if it wasn't told a timezone setting to use. We only moved this
examination of the system's behavior from every-postmaster-start to
initdb.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rob Sargent 2014-02-04 22:48:50 Re: The timezone oddities
Previous Message AlexK 2014-02-04 21:15:05 Re: Is it reasonable to store double[] arrays of 30K elements