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: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, 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-20T18:24:07Z
Lists: pgsql-hackers 
Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Thu, Jun 20, 2019 at 1:28 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> > I suppose we could have a moratorium on commits starting from (say) EOB
> > Wednesday of the week prior to the release; patches can only be
> > committed after that if they have ample support (where "ample support"
> > might be defined as having +1 from, say, two other committers).  That
> > way there's time to discuss/revert/fix anything that is deemed
> > controversial.
> 
> Or we could have a moratorium on any change at any time that has a -1
> from a committer and a +1 from nobody.

What about a change that's already been committed but another committer
feels caused a regression?  If that gets a -1, does it get reverted
until things are sorted out, or...?

In the situation that started this discussion, a change had already been
made and it was only later realized that it caused a regression.  Piling
on to that, the regression was entwined with other important changes
that we wanted to include in the release.

Having a system where when the commit was made is a driving factor seems
like it would potentially reward people who pushed a change early by
giving them the upper hand in such a discussion as this.

Ultimately though, I still agree with Andres that this is something we
should act to avoid these situation and we shouldn't try to make a
policy to fit what's been a very rare occurance.  If nothing else, I
feel like we'd probably re-litigate the policy every time since it would
likely have been a long time since the last discussion of it and the
specific circumstances will always be at least somewhat different.

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.