Message-ID: <38e73fef-f19b-4835-b353-a110db6c8318@technowledgy.de>
Date: Sun, 15 Sep 2024 11:08:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Wolfgang Walther <walther@technowledgy.de>
Subject: Re: Regression tests fail with tzdata 2024b
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
References: <0a997455-5aba-4cf2-a354-d26d8bcbfae6@technowledgy.de>
 <441306.1726346239@sss.pgh.pa.us>
Content-Language: en-US
In-Reply-To: <441306.1726346239@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/38e73fef-f19b-4835-b353-a110db6c8318%40technowledgy.de>
Precedence: bulk

Tom Lane:
> Also, as a real place to a greater extent
> than "PST8PDT" is, it's more subject to historical revisionism when
> somebody turns up evidence of local law having been different than
> TZDB currently thinks.

I now tried all versions of tzdata which we had in tree back to 2018g, 
they all work fine with the same regression test output. 2018g was an 
arbitrary cutoff, I just didn't try any further.

In the end, we don't need a default timezone that will never change. We 
just need one that didn't change in a reasonable number of releases 
going backwards. Once America/Los_Angeles is changed, we need to switch 
to a different zone, which could be one that wouldn't work today. Kind 
of a sliding window.

One positive might be: With this timezone, we are more likely to see 
relevant changes mentioned in the upstream release notes.

Best,

Wolfgang