Re: Time zone issue with 10.3?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Karl Denninger <karl(at)denninger(dot)net>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Time zone issue with 10.3?
Date: 2018-03-02 16:58:19
Message-ID: 30753.1520009899@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Karl Denninger <karl(at)denninger(dot)net> writes:
> I have just tried r0lling forward to 10.3 from 10.1 and suddenly my time
> zone declaration blew up.

> I was using 'US/Chicago' and was able to get the server to start with
> CST6CDT, which is the way the system is set up.  But I'm concerned about
> this, because I now get this from trying to query the system tables for
> timezone names:

> pgsql=# select * from pg_timezone_names;
>            name           | abbrev | utc_offset | is_dst
> --------------------------+--------+------------+--------
>  Canada/East-Saskatchewan | CST    | -06:00:00  | f
> (1 row)

> pgsql=# select * from pg_timezone_abbrevs;
> ERROR:  time zone "Asia/Yerevan" not recognized
> DETAIL:  This time zone name appears in the configuration file for time
> zone abbreviation "amst".

Hmm, is your build configured with --with-system-tzdata
(pg_config --configure would tell you)? If so, is that pointing at
a reasonable-looking tree of TZ data? It seems you don't have the
TZ data correctly installed in the 10.3 installation, but it's hard
to tell who to blame from this much info.

Typically the top of the TZ file tree should look like

$ ls /usr/share/zoneinfo
Africa/ Canada/ GB Indian/ Mexico/ ROK iso3166.tab
America/ Chile/ GB-Eire Iran NZ Singapore leapseconds
Antarctica/ Cuba GMT Israel NZ-CHAT Turkey posix/
Arctic/ EET GMT+0 Jamaica Navajo UCT posixrules
Asia/ EST GMT-0 Japan PRC US/ right/
Atlantic/ EST5EDT GMT0 Kwajalein PST8PDT UTC tzdata.zi
Australia/ Egypt Greenwich Libya Pacific/ Universal zone.tab
Brazil/ Eire HST MET Poland W-SU zone1970.tab
CET Etc/ Hongkong MST Portugal WET
CST6CDT Europe/ Iceland MST7MDT ROC Zulu

If you're not trying to rely on a platform-provided installation
of tzdata, then this ought to be under the share/ subdirectory
of the PG installation.

regards, tom lane

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Mike Lonergan 2018-03-02 17:00:35 What is the accepted practice to automate initdb (PostgreSQL 9.6) to a non-default directory?
Previous Message Karl Denninger 2018-03-02 16:49:17 Time zone issue with 10.3?