Re: BUG #15177: handling of the US/Pacific-New timezone
От | Tom Lane |
---|---|
Тема | Re: BUG #15177: handling of the US/Pacific-New timezone |
Дата | |
Msg-id | 28830.1524696787@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #15177: handling of the US/Pacific-New timezone (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #15177: handling of the US/Pacific-New timezone
|
Список | 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 по дате отправления: