Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.) - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
Date
Msg-id 87tvckypr5.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 >> I was referring to the fact that the regression was introduced by a,
 >> presumably important, tzdb update (2019a, as mentioned above). At
 >> least, I made the assumption that the commit of the import of 2019a
 >> had more than just the change that introduced the regression, but
 >> I'm happy to admit I'm no where near as close to the code here as
 >> you/Tom here.

 Tom> Keep in mind that dealing with whatever tzdb chooses to ship is
 Tom> not optional from our standpoint. Even if we'd refused to import
 Tom> 2019a, every installation using --with-system-tzdata (which, I
 Tom> sincerely hope, includes most production installs) is going to
 Tom> have to deal with it as soon as the respective platform vendor
 Tom> gets around to shipping the tzdata update. So reverting that
 Tom> commit was never on the table.

Exactly. But that means that if the combination of our arbitrary rules
and the data in the tzdb results in an undesirable result, then we have
no real option but to fix our rules (we can't reasonably expect the tzdb
upstream to choose zone names to make our alphabetical-order preference
come out right).

My commit was intended to be the minimum fix that would restore the
pre-2019a behavior on all systems.

-- 
Andrew (irc:RhodiumToad)



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
Next
From: David Fetter
Date:
Subject: Re: Tweaking DSM and DSA limits