From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Update time zone data files to tzdata release 2024b. |
Date: | 2024-10-30 23:07:56 |
Message-ID: | 871448.1730329676@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-10-30 23:20:05 | Re: pgsql: Update time zone data files to tzdata release 2024b. |
Previous Message | Tom Lane | 2024-10-30 22:43:36 | Re: pgsql: Update time zone data files to tzdata release 2024b. |