Re: BUG #15177: handling of the US/Pacific-New timezone - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #15177: handling of the US/Pacific-New timezone
Date
Msg-id 28830.1524696787@sss.pgh.pa.us
Whole thread Raw
In response to BUG #15177: handling of the US/Pacific-New timezone  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #15177: handling of the US/Pacific-New timezone
List pgsql-bugs
=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
> We recently upgraded our PostgreSQL install from 9.6.5 to 9.6.8,
> and now we have a serious problem that blocks access to the database.
> We tracked it down to a change in PostgreSQL 9.6.7, wherein support for
> the US/Pacific-New timezone was dropped.  This timezone *must* be restored
> to a standard-release database, in spite of the prior release notes that
> dismissed it as just an alias for another timezone.  Let me explain.

I suggest complaining to the IANA timezone mailing list, see
https://www.iana.org/time-zones

If you can persuade them to put back Pacific-New in the standard
distribution of the TZ database, we'll happily track that.  We are
not, however, going to ship a non-default version of that database.
It's hard enough tracking the standard one.

Alternatively, you can install your own version of the TZ files,
customized however you like.  If you have as many constraints on
(mis) behavior of the TZ data as you seem to indicate, I'm not
sure you really want to be tracking IANA updates at all.  They
frequently change their entries when they find better info about
old timekeeping practices, and of course the politicians of the
world keep changing current/future practices.  If you can't tolerate
the zone definitions moving under you, you're guaranteed to get
burnt sooner or later, unless you freeze that data set as it
was at some-random-date.

            regards, tom lane


pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15177: handling of the US/Pacific-New timezone
Next
From: Jeff Janes
Date:
Subject: Re: BUG #15173: why small gin_fuzzy_search_limit search more blocksthan big gin_fuzzy_search_limit ?