| 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: | Whole Thread | Raw Message | 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. |