| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | eponymousalias(at)yahoo(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #15177: handling of the US/Pacific-New timezone |
| Date: | 2018-04-26 01:45:09 |
| Message-ID: | 20180426014509.GB18940@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Apr 25, 2018 at 06:53:07PM -0400, Tom Lane wrote:
> 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.
There are a couple of ways to achieve that, one being to use configure's
--with-system-tzdata to point to a custom timezone folder which is
useful when it comes to packaging. Another simple way to do that would
be to revert a portion of commit 41fc04ff which updated the database to
2018c and add back the link America/Los_Angeles -> US/Pacific-New. But
after that you are on your own with a custom patch.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | 德哥 | 2018-04-26 05:45:20 | Re:Re: BUG #15173: why small gin_fuzzy_search_limit search more blocks than big gin_fuzzy_search_limit ? |
| Previous Message | Jeff Janes | 2018-04-26 00:52:16 | Re: BUG #15173: why small gin_fuzzy_search_limit search more blocks than big gin_fuzzy_search_limit ? |