On Thu, Sep 13, 2018 at 11:20 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael@paquier.xyz> writes:
> > On Wed, Sep 12, 2018 at 10:00:21AM -0400, Tom Lane wrote:
> >> I believe that this patch will never make for any functional change,
> >> it will only give you some other alias for the zone it would have
> >> selected anyway.
>
> > Looking at the list of aliases, I am not seeing listed countries running
> > across multiple timezones, so that may be fine.
>
> Not sure what you're worried about. "Linked" time zones are the *same
> data*. In an installed tzdb tree, the Japan file is either a hardlink or
> symlink to the Asia/Tokyo one, so they can't differ. What you seem to be
> speculating about is actual errors in the tzdb data, ie not describing
> the facts on the ground in particular places. That's possible I suppose
> but it's hardly our problem if it happens; it'd be theirs to fix.
I tested this on a system where /etc/localtime is not a symlink
(FreeBSD) and it worked fine, falling back to the old behaviour and
finding my timezone. (Apparently the argument against a symlink
/etc/localtime -> /usr/share/tzinfo/... is that new processes would
effectively switch timezone after /usr is mounted so your boot logs
would be mixed up. Or something. I bet that actually happens on
Linux too, but maybe no one does /usr as a mount point anymore...?)
I noticed that the patch does a bunch of s/Olson/IANA/. That leaves
only one place in the tree that still refers to the "Olson" database:
dt_common.c. Might want to change that too?
--
Thomas Munro
http://www.enterprisedb.com