Victor Wagner <vi...@wagner.pp.ru> writes:
> Tom Lane <t...@sss.pgh.pa.us> пишет:
>> Fun. I bet that breaks more than just Pacific/Enderbury.
>> Can you try changing that entry to Pacific/Kanton, and repeat?
> I did. No more problems.
> I.e. I've invoked
> sed -i 's/Enderburry/Kanton/' $prefix/share/timezonesets/*
> and rerun tests. No failures.
I was concerned about the non-Default timezonesets too, but
having now spun up a copy of Ubuntu 23.10 I see that those
work fine once Default is fixed. So indeed this is the only
zone causing us problems. That's probably because only a
relatively small fraction of the timezonesets entries depend
explicitly on named zones --- most of them are just numeric
UTC offsets.
Anyway, looking into the tzdata NEWS file I found
Release 2021b - 2021-09-24 16:23:00 -0700
Rename Pacific/Enderbury to Pacific/Kanton. When we added
Enderbury in 1993, we did not know that it is uninhabited and that
Kanton (population two dozen) is the only inhabited location in
that timezone. The old name is now a backward-compatibility link.
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?
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
