I nomi dei fusi orari con proprietà identiche producono risultati diversi quando applicati al timestamp

Subito dopo aver pubblicato questo, ho eseguito un'altra query per verificare un sospetto:

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

A quanto pare, c'è anche una abbreviazione del fuso orario denominato CET (che ha senso, "CET" è un'abbreviazione). E sembra che PostgreSQL scelga l'abbreviazione sul nome completo. Quindi, anche se ho trovato CET nel fuso orario nomi , l'espressione '2012-01-18 1:0 CET'::timestamptz viene interpretata secondo regole leggermente diverse per le abbreviazioni del fuso orario .

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

Trovo 10 casi di abbreviazioni del fuso orario nel fuso orario nomi e non riesco a capire perché quelli ci sono. Qual è lo scopo?

Tra questi, il time offset (utc_offset ) non è d'accordo in quattro casi a causa dell'impostazione dell'ora legale:

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 questi casi, le persone possono essere ingannate (come me), cercando il nome tz e trovare un offset temporale che non è effettivamente applicato. Questo è un design sfortunato - se non un bug, almeno un bug di documentazione .

Non riesco a trovare nulla nel manuale su come ambiguità tra i nomi del fuso orario e abbreviazioni sono risolti. Ovviamente le abbreviazioni hanno la precedenza.

Appendice B.1. L'interpretazione dell'immissione di data/ora menziona la ricerca delle abbreviazioni del fuso orario, ma rimane non chiara come fuso orario nomi vengono identificati e quale di essi ha la priorità in caso di token ambiguo.