Horton

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

Stephen Frost <sfrost@snowman.net>

View thread View on postgr.es
From: Stephen Frost <sfrost@snowman.net>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andrew Gierth <andrew@tao11.riddles.org.uk>, Christoph Berg <myon@debian.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-06-20T17:26:58Z
Lists: pgsql-hackers 
Greetings,

* Andres Freund (andres@anarazel.de) wrote:
> On 2019-06-20 12:02:30 -0400, Robert Haas wrote:
> > On Thu, Jun 20, 2019 at 8:52 AM Stephen Frost <sfrost@snowman.net> wrote:
> > > I don't want to come across as implying that I'm saying what was done
> > > was 'fine', or that we shouldn't be having this conversation, I'm just
> > > trying to figure out how we can frame it in a way that we learn from it
> > > and work to improve on it for the future, should something like this
> > > happen again.
> > 
> > I agree that it's a difficult situation.  I do kind of wonder whether
> > we were altogether overreacting.  If we had shipped it as it was,
> > what's the worst thing that would have happened?
> 
> I think it's not good, but also nothing particularly bad came out of
> it. I don't think we should try to set up procedures for future
> occurances, and rather work/plan on that not happening very often.

Agreed.

Thanks,

Stephen

Commits

  1. Tweak our special-case logic for the IANA "Factory" timezone.

  2. Avoid choosing "localtime" or "posixrules" as TimeZone during initdb.

  3. Prefer timezone name "UTC" over alternative spellings.

  4. Attempt to identify system timezone by reading /etc/localtime symlink.

  5. Update time zone data files to tzdata release 2019a.