Re: pgsql: Update time zone data files to tzdata release 2024b.
От
Tom Lane
Тема
Re: pgsql: Update time zone data files to tzdata release 2024b.
Дата
Msg-id
871448.1730329676@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
pgsql: Update time zone data files to tzdata release 2024b. Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Update time zone data files to tzdata release 2024b. Andrew Dunstan <andrew@dunslane.net>
Re: pgsql: Update time zone data files to tzdata release 2024b. Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Update time zone data files to tzdata release 2024b. Andrew Dunstan <andrew@dunslane.net>
Re: pgsql: Update time zone data files to tzdata release 2024b. Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Update time zone data files to tzdata release 2024b. Andrew Dunstan <andrew@dunslane.net>
Re: pgsql: Update time zone data files to tzdata release 2024b. Tom Lane <tgl@sss.pgh.pa.us>
I wrote: > ... So I'm fuzzy about the exact details of > what has happened on crake, but I'm pretty sure that it boils > down to "the dump timezone changed since 2018". Oh ... never mind, I was thinking in terms of what would happen with --use-system-timezone, but of course the buildfarm doesn't build that way. So the problem is precisely that *our* interpretation of EST5EDT changed when we adopted tzdata 2024b, and that is affecting how we dump these old timestamps. Or at least, that seems like what should be happening, but then why is only crake showing a failure? > I'm inclined to propose that we should modify the pg_upgrade test > so that it forces the comparison dumps to be taken with PGTZ=UTC, > thereby taking system-timezone changes out of the picture. Whatever the details exactly, this still seems like a good future-proof fix. I'm not quite sure where we need to make the change though --- if I edit pg_upgrade/t/002_pg_upgrade.pl, will that affect how the buildfarm tests these things, or is it different code? regards, tom lane
В списке pgsql-committers по дате отправления
От: Tom Lane
Дата:
От: Tom Lane
Дата: