Tidszonnamn med identiska egenskaper ger olika resultat när de tillämpas på tidsstämpel

Direkt efter att jag postade detta, körde jag en annan fråga för att kontrollera en misstanke:

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

Som det visar sig finns också en tidszon förkortning heter CET (vilket är vettigt, "CET" är en förkortning). Och det verkar som att PostgreSQL väljer förkortningen framför hela namnet. Så även om jag hittade CET i tidszonen namn , uttrycket '2012-01-18 1:0 CET'::timestamptz tolkas enligt de subtilt olika reglerna för tidszons förkortningar .

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

Jag hittar 10 fall av tidszonförkortningar i tidszonen namn och misslyckas med att förstå varför de finns där. Vad är syftet?

Bland dessa är tidsförskjutningen (utc_offset ) håller inte med i fyra fall på grund av sommartid:

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

I dessa fall kan folk bli lurade (som jag blev genom att leta upp tz namn och hitta en tidsförskjutning som faktiskt inte tillämpas. Det är en olycklig design - om inte en bugg, åtminstone en dokumentationsbugg .

Jag kan inte hitta något i manualen om hur oklarheter mellan tidszons namn och förkortningar är lösta. Uppenbarligen har förkortningar företräde.

Bilaga B.1. Tolkning av inmatning av datum/tid nämner uppslagningen efter tidszonförkortningar, men den förblir otydlig hur tidszon namn identifieras och vilka av dem har prioritet i händelse av en tvetydig token.

Om token är en textsträng, matcha med möjliga strängar:

Gör en tabellsökning med binär sökning efter token som en tidszonförkortning.

Tja, det finns en liten antydan i den här meningen att förkortningar kommer först, men inget definitivt. Det finns också en kolumn abbrev i båda tabellerna, pg_timezone_names och pg_timezone_abbrevs ...