mirror of
https://github.com/postgres/postgres.git
synced 2026-04-26 00:31:07 -04:00
d1537afe3e
Debian recently decided to split out a bunch of "obsolete" timezone names into a new tzdata-legacy package, which isn't installed by default. One of these zone names is Pacific/Enderbury, and that breaks our regression tests (on --with-system-tzdata builds) because our default timezone abbreviations list defines PHOT as Pacific/Enderbury. Pacific/Enderbury got renamed to Pacific/Kanton in tzdata 2021b, so that in distros that still have this entry it's just a symlink to Pacific/Kanton anyway. So one answer would be to redefine PHOT as Pacific/Kanton. However, then things would fail if the installed tzdata predates 2021b, which is recent enough that that seems like a real problem. Instead, let's just remove PHOT from the default list. That seems likely to affect nobody in the real world, because (a) it was an abbreviation that the tzdb crew made up in the first place, with no evidence of real-world usage, and (b) the total human population of the Phoenix Islands is less than two dozen persons, per Wikipedia. If anyone does use this zone abbreviation they can easily put it back via a custom abbreviations file. We'll keep PHOT in the Pacific.txt reference file, but change it to Pacific/Kanton there, as that definition seems more likely to be useful to future readers of that file. Per report from Victor Wagner. Back-patch to all supported branches. Discussion: https://postgr.es/m/20231027152049.4b5c8044@wagner.wagner.home |
||
|---|---|---|
| .. | ||
| Africa.txt | ||
| America.txt | ||
| Antarctica.txt | ||
| Asia.txt | ||
| Atlantic.txt | ||
| Australia | ||
| Australia.txt | ||
| Default | ||
| Etc.txt | ||
| Europe.txt | ||
| India | ||
| Indian.txt | ||
| Makefile | ||
| meson.build | ||
| Pacific.txt | ||
| README | ||
src/timezone/tznames/README tznames ======= This directory contains files with timezone sets for PostgreSQL. The problem is that time zone abbreviations are not unique throughout the world and you might find out that a time zone abbreviation in the `Default' set collides with the one you wanted to use. This can be fixed by selecting a timezone set that defines the abbreviation the way you want it. There might already be a file here that serves your needs. If not, you can create your own. In order to use one of these files, you need to set timezone_abbreviations = 'xyz' in any of the usual ways for setting a parameter, where xyz is the filename that contains the desired time zone abbreviations. If you do not find an appropriate set of abbreviations for your geographic location supplied here, please report this to <pgsql-hackers@lists.postgresql.org>. Your set of time zone abbreviations can then be included in future releases. For the time being you can always add your own set. Typically a custom abbreviation set is made by including the `Default' set and then adding or overriding abbreviations as necessary. For examples, see the `Australia' and `India' files. The files named Africa.txt, etc, are not intended to be used directly as time zone abbreviation files. They contain reference definitions of time zone abbreviations that can be copied into a custom abbreviation file as needed. These files contain most of the time zone abbreviations that were shown in the IANA timezone database circa 2010. However, it turns out that many of these abbreviations had simply been invented by the IANA timezone group, and do not have currency in real-world use. The IANA group have changed their policy about that, and now prefer to use numeric UTC offsets whenever there's not an abbreviation with known real-world popularity. A lot of these abbreviations therefore no longer appear in the IANA data, and so are marked "obsolete" in these data files.