Tepat setelah saya memposting ini, saya menjalankan kueri lain untuk memeriksa kecurigaan:
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
Ternyata, ada juga zona waktu singkatan bernama CET
(yang masuk akal, "CET" adalah singkatan). Dan tampaknya PostgreSQL memilih singkatan dari nama lengkapnya. Jadi, meskipun saya menemukan CET
di zona waktu nama , ekspresi '2012-01-18 1:0 CET'::timestamptz ditafsirkan menurut aturan yang agak berbeda untuk singkatan zona waktu .
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
Saya menemukan 10 kasus zona waktu singkatan di zona waktu nama dan gagal untuk memahami mengapa mereka ada di sana. Apa tujuannya?
Diantaranya, offset waktu (utc_offset
) tidak setuju dalam empat kasus karena pengaturan DST:
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
Dalam kasus ini, orang mungkin tertipu (seperti saya), mencari namatz dan menemukan offset waktu yang sebenarnya tidak diterapkan. Itu adalah desain yang disayangkan - jika bukan bug, setidaknya bug dokumentasi .
Saya gagal menemukan apa pun di manual tentang bagaimana ambiguitas antara nama zona waktu dan singkatan diselesaikan. Jelas singkatan diutamakan.
Lampiran B.1. Interpretasi Masukan Tanggal/Waktu menyebutkan pencarian singkatan zona waktu, namun tetap tidak jelas bagaimana zona waktu nama diidentifikasi dan mana dari mereka yang memiliki prioritas dalam kasus token yang ambigu.
Jika token adalah string teks, cocokkan dengan kemungkinan string:
Lakukan pencarian tabel pencarian biner untuk token sebagai singkatan zona waktu.
Nah, ada sedikit petunjuk dalam kalimat ini bahwa singkatan didahulukan, tetapi tidak ada yang pasti. Juga, ada kolom abbrev
di kedua tabel, pg_timezone_names
dan pg_timezone_abbrevs
...