From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Update time zone data files to tzdata release 2024b. |
Date: | 2024-10-29 23:06:19 |
Message-ID: | 55A5E01C-1B0F-40F9-94EA-FEDED1575C92@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
> On Oct 29, 2024, at 5:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> Crake doesn't seem to like this for cross version upgrade, and the diff
>> looks rather odd:
>
> Oh, that's annoying. I forgot to mention the side-effects that 2024b
> had on PST8PDT and other SysV-derived timezones (probably because Paul
> Eggert avoided mentioning that in his release notes ... thanks for
> nothing Paul). What we've got there is that sufficiently old
> timestamps (pre 1890 or so) are now interpreted as local mean solar
> time for Los Angeles rather than exactly UTC-8.
>
> I would expect that the upgrade tests would pass now for upgrades
> from v12 or later, thanks to b8ea0f675 et al, but I'm not real
> sure what to do about testing the out-of-support branches. Should
> we back-patch b8ea0f675 as far down as 9.2?
>
>
Or fix/remove the problem rows in AdjustUpgrade.pm I guess
Cheers
Andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2024-10-30 07:18:58 | pgsql: Replicate generated columns when specified in the column list. |
Previous Message | Tom Lane | 2024-10-29 22:41:06 | Re: pgsql: Update time zone data files to tzdata release 2024b. |