Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
От | Andrew Gierth |
---|---|
Тема | Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.) |
Дата | |
Msg-id | 87y31wytdl.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: UCT (Re: pgsql: Update time zone data files to tzdata release2019a.) (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: UCT (Re: pgsql: Update time zone data files to tzdata release2019a.)
Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.) |
Список | pgsql-hackers |
>>>>> "Stephen" == Stephen Frost <sfrost@snowman.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) 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). 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? -- Andrew (irc:RhodiumToad)
В списке pgsql-hackers по дате отправления: