Tidszonenavne med identiske egenskaber giver forskellige resultater, når de anvendes på tidsstemplet

Lige efter jeg havde postet dette, kørte jeg en anden forespørgsel for at kontrollere en mistanke:

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 viser sig, er der også en tidszone forkortelse navngivet CET (hvilket giver mening, "CET" er en forkortelse). Og det ser ud til, at PostgreSQL vælger forkortelsen over det fulde navn. Så selvom jeg fandt CET i tidszonen navne , udtrykket '2012-01-18 1:0 CET'::timestamptz fortolkes i overensstemmelse med de subtilt forskellige regler for tidszone forkortelser .

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

Jeg finder 10 tilfælde af tidszoneforkortelser i tidszonen navne og forstår ikke hvorfor de er der. Hvad er formålet?

Blandt disse er tidsforskydningen (utc_offset ) er uenig i fire tilfælde på grund af DST-indstillingen:

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 disse tilfælde kan folk blive narret (som jeg var ved at slå op på tz navn). og finde en tidsforskydning, der faktisk ikke anvendes. Det er et uheldigt design - hvis ikke en fejl, i det mindste en dokumentationsfejl .

Jeg kan ikke finde noget i manualen om, hvordan uklarheder mellem tidszone navne og forkortelser er løst. Det er klart, at forkortelser har forrang.

Bilag B.1. Fortolkning af dato/tidsindtastning nævner opslag efter tidszoneforkortelser, men det forbliver uklart hvordan tidszone navne er identificeret, og hvem af dem har prioritet i tilfælde af en tvetydig token.