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

Greetings,

* Andrew Gierth (andrew(at)tao11(dot)riddles(dot)org(dot)uk) wrote:
> >>>>> "Stephen" == Stephen Frost <sfrost(at)snowman(dot)net> writes:
>
> Stephen> In the situation that started this discussion, a change had
> Stephen> already been made and it was only later realized that it
> Stephen> caused a regression.
>
> Just to keep the facts straight:
>
> The regression was introduced by importing tzdb 2019a (in late April)

Ah, thanks, I had misunderstood when that was committed then.

> into the previous round of point releases; the change in UTC behaviour
> was not mentioned in the commit and presumably didn't show up on
> anyone's radar until there were field complaints (which didn't reach our
> mailing lists until Jun 4 as far as I know).

Ok.

> Tom's "fix" of backpatching 23bd3cec6 (which happened on Friday 14th)
> addressed only a subset of cases, as far as I know working only on Linux
> (the historical convention has always been for /etc/localtime to be a
> copy of a zonefile, not a symlink to one). I only decided to write (and
> if need be commit) my own followup fix after confirming that the bug was
> unfixed in a default FreeBSD install when set to UTC, and there was a
> good chance that a number of other less-popular platforms were affected
> too.
>
> Stephen> Piling on to that, the regression was entwined with other
> Stephen> important changes that we wanted to include in the release.
>
> I'm not sure what you're referring to here?

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.

Thanks,

Stephen