PostgreSQL
 sql >> Teknologi Basis Data >  >> RDS >> PostgreSQL

Nama zona waktu dengan properti yang identik menghasilkan hasil yang berbeda ketika diterapkan pada stempel waktu

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 ...



  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Cara membuat daftar semua database menggunakan PostgreSQL

  2. Penyesuaian PostgreSQL:Hal Utama untuk Mendorong Kinerja

  3. Bagaimana cara mengkonfigurasi HikariCP untuk postgresql?

  4. Izinkan null di kolom unik

  5. Ikhtisar Pemrosesan VACUUM di PostgreSQL