Namen van tijdzones met identieke eigenschappen leveren een ander resultaat op wanneer toegepast op tijdstempel

Direct nadat ik dit had gepost, voerde ik nog een vraag uit om een ​​vermoeden te controleren:

SELECT * FROM pg_timezone_abbrevs
WHERE  abbrev IN ('CEST', 'CET');

 abbrev | utc_offset | is_dst
--------+------------+--------
 CEST   | 02:00:00   | t
 CET    | 01:00:00   | f

Het blijkt dat er ook . is een tijdzone afkorting genaamd CET (wat logisch is, "CET" is een afkorting). En het lijkt erop dat PostgreSQL de afkorting kiest boven de volledige naam. Dus ook al vond ik CET in de tijdzone namen , wordt de uitdrukking '2012-01-18 1:0 CET'::timestamptz geïnterpreteerd volgens de subtiel verschillende regels voor tijdzone afkortingen .

SELECT '2012-01-18 1:0 CEST'::timestamptz(0)
      ,'2012-01-18 1:0 CET'::timestamptz(0)
      ,'2012-01-18 1:0 Europe/Vienna'::timestamptz(0);

      timestamptz       |      timestamptz       |      timestamptz
------------------------+------------------------+------------------------
 2012-01-18 00:00:00+01 | 2012-01-18 01:00:00+01 | 2012-01-18 01:00:00+01


SELECT '2012-08-18 1:0 CEST'::timestamptz(0)
      ,'2012-08-18 1:0 CET'::timestamptz(0)
      ,'2012-08-18 1:0 Europe/Vienna'::timestamptz(0);

      timestamptz       |      timestamptz       |      timestamptz
------------------------+------------------------+------------------------
 2012-08-18 01:00:00+02 | 2012-08-18 02:00:00+02 | 2012-08-18 01:00:00+02

Ik vind 10 gevallen van tijdzone afkortingen in de tijdzone namen en niet begrijpen waarom die er zijn. Wat is het doel?

Hiertoe behoort de tijdverschuiving (utc_offset ) is het in vier gevallen niet eens vanwege de zomertijdinstelling:

SELECT n.*, a.*
FROM   pg_timezone_names n 
JOIN   pg_timezone_abbrevs a ON  a.abbrev = n.name
WHERE  n.utc_offset <> a.utc_offset;

 name | abbrev | utc_offset | is_dst | abbrev | utc_offset | is_dst
------+--------+------------+--------+--------+------------+--------
 CET  | CEST   | 02:00:00   | t      | CET    | 01:00:00   | f
 EET  | EEST   | 03:00:00   | t      | EET    | 02:00:00   | f
 MET  | MEST   | 02:00:00   | t      | MET    | 01:00:00   | f
 WET  | WEST   | 01:00:00   | t      | WET    | 00:00:00   | f

In deze gevallen kunnen mensen voor de gek worden gehouden (zoals ik deed) door de tz naam . op te zoeken en het vinden van een tijdsverschuiving die niet daadwerkelijk wordt toegepast. Dat is een ongelukkig ontwerp - zo niet een bug, dan tenminste een documentatiebug .

Ik kan niets vinden in de handleiding over hoe dubbelzinnigheden tussen tijdzone namen en afkortingen zijn opgelost. Uiteraard hebben afkortingen voorrang.

Bijlage B.1. Datum/tijd-invoerinterpretatie vermeldt het opzoeken van afkortingen voor tijdzones, maar het blijft onduidelijk hoe tijdzone namen worden geïdentificeerd en welke van hen prioriteit heeft in het geval van een ambigue token.