From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Update time zone data files to tzdata release 2024b.
In-reply-to: 
 <CAD5tBcLNF7vq8PnCOS11kqxueXhXd7+3SvwtjPPc2zKZ2hQ3TQ@mail.gmail.com>
References: <E1t5oUR-0031eD-7j@gemulon.postgresql.org>
 <CAD5tBcLNF7vq8PnCOS11kqxueXhXd7+3SvwtjPPc2zKZ2hQ3TQ@mail.gmail.com>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Tue, 29 Oct 2024 17:44:56 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <362288.1730241666.1@sss.pgh.pa.us>
Date: Tue, 29 Oct 2024 18:41:06 -0400
Message-ID: <362289.1730241666@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/362289.1730241666%40sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew@dunslane.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