| 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-29 22:41:06 |
| Message-ID: | 362289.1730241666@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2024-10-29 23:06:19 | Re: pgsql: Update time zone data files to tzdata release 2024b. |
| Previous Message | Andrew Dunstan | 2024-10-29 21:44:56 | Re: pgsql: Update time zone data files to tzdata release 2024b. |