From: | Victor Wagner <vitus(at)wagner(dot)pp(dot)ru> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Enderbury Island disappeared from timezone database |
Date: | 2023-10-28 13:48:29 |
Message-ID: | 20231028164829.45b6d96a@wagner.wagner.home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
В Fri, 27 Oct 2023 14:00:38 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> пишет:
> This means that if we substitute Kanton for Enderbury, things
> will work fine against tzdata 2021b or later, but will fail in
> the reverse way against older tzdata sets. Do we want to
> bet that everybody in the world has up-to-date tzdata installed?
You are right. When nightly builds came, they showed problems with
Pacific/Kanton in
Debian 10, 11 and Ubuntu 20.04 (we do not more test ubuntu 18.04 as 5
year support period is ended).
I haven't applied 'fix' to rpm-based disitrubutions, because none of
them as I'm aware of split tzdata into two packages.
> I guess the contract for using --with-system-tzdata is that it's
> up to you to maintain that, but still I don't like the odds.
>
> The alternative I'm wondering about is whether to just summarily
> remove the PHOT entry from timezonesets/Default. It's a made-up
> zone abbreviation in the first place, and per the above NEWS entry,
> there's only a couple dozen people in the world who might even
> be candidates to consider using it. It seems highly likely that
> nobody would care if we just dropped it from the Default list.
> (We could keep the Pacific.txt entry, although re-pointing it
> to Pacific/Kanton seems advisable.)
>
> regards, tom lane
>
>
--
Victor Wagner <vitus(at)wagner(dot)pp(dot)ru>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-10-28 15:28:29 | Re: Enderbury Island disappeared from timezone database |
Previous Message | Michael Paquier | 2023-10-28 11:01:46 | Re: maybe a type_sanity. sql bug |