Nazwy stref czasowych o identycznych właściwościach dają różne wyniki po zastosowaniu do znacznika czasu

Zaraz po tym, jak to opublikowałem, uruchomiłem kolejne zapytanie, aby sprawdzić podejrzenie:

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

Jak się okazuje, istnieje również strefa czasowa skrót o nazwie CET (co ma sens, ponieważ „CET” jest skrótem). I wygląda na to, że PostgreSQL wybiera skrót zamiast pełnej nazwy. Tak więc, mimo że znalazłem CET w strefie czasowej nazwy , wyrażenie „2012-01-18 1:0 CET”::timestamptz jest interpretowane zgodnie z nieco innymi regułami dotyczącymi skrótów stref czasowych .

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

Znalazłem 10 przypadków skrótów stref czasowych w strefie czasowej nazwy i nie rozumiem, dlaczego one tam są. Jaki jest cel?

Wśród nich przesunięcie czasu (utc_offset ) nie zgadza się w czterech przypadkach ze względu na ustawienie czasu letniego:

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

W takich przypadkach ludzie mogą zostać oszukani (tak jak ja), wyszukując tz imię i znalezienie przesunięcia czasu, które nie jest faktycznie stosowane. To niefortunny projekt - jeśli nie błąd, to przynajmniej błąd dokumentacji .

W instrukcji nie mogę znaleźć niczego o niejasnościach między nazwami stref czasowych i skróty są rozwiązane. Oczywiście pierwszeństwo mają skróty.

Dodatek B.1. Interpretacja wprowadzania daty/godziny wspomina o wyszukiwaniu skrótów stref czasowych, ale pozostaje niejasne jak strefy czasowe nazwy są zidentyfikowane i który z nich ma pierwszeństwo w przypadku niejednoznacznego tokena.