Thread: Enderbury Island disappeared from timezone database
Collegues,
I've encountered following problem compiling PostgreSQL 15.4 with just
released Ubuntu 23.10.
I'm compiling postgres with --with-system-tzdata and then regression
test sysviews fails with following diff:
--- /home/test/pg-tests/postgresql-15.4/src/test/regress/expected/sysviews.out 2023-10-26 19:06:02.000000000 +0000
+++ /home/test/pg-tests/postgresql-15.4/src/test/regress/results/sysviews.out 2023-10-27 07:10:22.214698986 +0000
@@ -147,23 +147,14 @@
(1 row)
select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
- ok
-----
- t
-(1 row)
-
+ERROR: time zone "Pacific/Enderbury" not recognized
+DETAIL: This time zone name appears in the configuration file for time zone abbreviation "phot".
with more such errors follows.
Investigation shows, that this timezone was long ago declared
deprecated, and eventually disappeared from tzdata package in Ubuntu
even as symlink to Pasific/Kanton (which is equivalent).
But this timezone present in src/timezone/tznames/Default, so this
error message is appears any time one access pg_timezone_abbrevs
regardless of Pacific region is included in results or not.
May be, Enderbury should be replaced by Kanton in
src/timezone/tznames/Default and src/timezone/tznames/Pacific.txt?
--
Victor Wagner <vitus@wagner.pp.ru>
Victor Wagner <vitus@wagner.pp.ru> writes:
> I've encountered following problem compiling PostgreSQL 15.4 with just
> released Ubuntu 23.10.
> I'm compiling postgres with --with-system-tzdata and then regression
> test sysviews fails with following diff:
> +ERROR: time zone "Pacific/Enderbury" not recognized
> +DETAIL: This time zone name appears in the configuration file for time zone abbreviation "phot".
Hmph. Pacific/Enderbury is still defined according to tzdata 2023c,
which is the latest release:
$ grep Enderbury src/timezone/data/tzdata.zi
L Pacific/Kanton Pacific/Enderbury
Did Ubuntu decide to remove *all* backzone links from their data?
Or just that one? Either way, I think they're going to get a tsunami
of pushback pretty quickly. People like their obsolete zone names.
regards, tom lane
В Fri, 27 Oct 2023 10:25:57 -0400
Tom Lane <tgl@sss.pgh.pa.us> пишет:
> Victor Wagner <vitus@wagner.pp.ru> writes:
> > I've encountered following problem compiling PostgreSQL 15.4 with
> > just released Ubuntu 23.10.
>
> > I'm compiling postgres with --with-system-tzdata and then regression
> > test sysviews fails with following diff:
> > +ERROR: time zone "Pacific/Enderbury" not recognized
> > +DETAIL: This time zone name appears in the configuration file for
> > time zone abbreviation "phot".
>
> Hmph. Pacific/Enderbury is still defined according to tzdata 2023c,
> which is the latest release:
>
> $ grep Enderbury src/timezone/data/tzdata.zi
> L Pacific/Kanton Pacific/Enderbury
>
> Did Ubuntu decide to remove *all* backzone links from their data?
> Or just that one? Either way, I think they're going to get a tsunami
> of pushback pretty quickly. People like their obsolete zone names.
They split tzdata packages into tzdata and tzdata-legacy (just for
those who like obsolete zone names), and into latter one gone 121 links,
not counting "right" subdirectory. It is actually Debian unstable
feature that got impored into ubuntu. But my
test machines with debian testing do not use --with-system-tzdata, so
I've not noticed this earlier.
It has following entry in changelog:
tzdata (2023c-8) unstable; urgency=medium
* Update Dutch debconf translation.
Thanks to Frans Spiesschaert <Frans.Spiesschaert@yucom.be>
(Closes: #1041278)
* Ship only timezones in tzdata that follow the current rules of
geographical
region (continent or ocean) and city name. Move all legacy timezone
symlinks
(that are upgraded during package update) to tzdata-legacy. This
includes
dropping the special handling for US/* timezones. (Closes: #1040997)
-- Benjamin Drung <bdrung@debian.org> Mon, 07 Aug 2023 15:02:14 +0200
I.e. they move obsolete timezones into separate package just for people
who like them.
Description of that package ends with:
This package also contains legacy timezone symlinks that are not
following
the current rule of using the geographical region (continent or ocean)
and
city name.
.
You do not need this package if you are unsure.
Really I think that if at least some distirbutions don't like this
names, it is better to have postgres pass its regression tests without
these names as well as with them.
--
Victor Wagner <vitus@wagner.pp.ru>
Victor Wagner <vitus@wagner.pp.ru> writes:
> Tom Lane <tgl@sss.pgh.pa.us> пишет:
>> Did Ubuntu decide to remove *all* backzone links from their data?
>> Or just that one? Either way, I think they're going to get a tsunami
>> of pushback pretty quickly. People like their obsolete zone names.
> They split tzdata packages into tzdata and tzdata-legacy (just for
> those who like obsolete zone names), and into latter one gone 121 links,
> not counting "right" subdirectory.
Fun. I bet that breaks more than just Pacific/Enderbury.
Can you try changing that entry to Pacific/Kanton, and repeat?
And then check the non-Default timezonesets lists too?
regards, tom lane
В Fri, 27 Oct 2023 11:17:03 -0400
Tom Lane <tgl@sss.pgh.pa.us> пишет:
> Victor Wagner <vitus@wagner.pp.ru> writes:
> > Tom Lane <tgl@sss.pgh.pa.us> пишет:
> >> Did Ubuntu decide to remove *all* backzone links from their data?
> >> Or just that one? Either way, I think they're going to get a
> >> tsunami of pushback pretty quickly. People like their obsolete
> >> zone names.
>
> > They split tzdata packages into tzdata and tzdata-legacy (just for
> > those who like obsolete zone names), and into latter one gone 121
> > links, not counting "right" subdirectory.
>
> 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.
It seems that Pacific/Enerberry was only one obsolete name which got
its way into abbreviations list.
> And then check the non-Default timezonesets lists too?
Enderbury аppears in two files in the timezonesets - Default
and Pacific.txt.
--
Victor Wagner <vitus@wagner.pp.ru>
Victor Wagner <vitus@wagner.pp.ru> writes:
> Tom Lane <tgl@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
В Fri, 27 Oct 2023 14:00:38 -0400
Tom Lane <tgl@sss.pgh.pa.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@wagner.pp.ru>
Victor Wagner <vitus@wagner.pp.ru> writes:
> Tom Lane <tgl@sss.pgh.pa.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).
OK. Let's just remove the PHOT entry then. It's not like it's
hard to make a custom abbreviation list, in case there's actually
somebody out there who needs it.
regards, tom lane