Обсуждение: Time zone issue with 10.3?

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

Rolling the binaries back (gmake install) from the previous 10.1 build (which I still have) did not clear this.  I'm not sure what happened here, or whether it will bite me (and if so, how hard), but the place I expect this to cause trouble in my calendar app which does allow various timezones to be selected....

Any ideas on what happened?

Karl Denninger <karl@denninger.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

On 3/2/2018 10:58, Tom Lane wrote:

Karl Denninger <karl@denninger.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

I found it; there was a permission problem during the install and Postgres' startup, when reading those files, apparently didn't complain about it -- it just didn't load them all (but did load others!) and that resulted in an inconsistency that made things very angry..... :-)

Sorry about the false alarm....