PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

Имената на часови зони с идентични свойства дават различен резултат, когато се прилагат към времеви печат

Веднага след като публикувах това, пуснах друга заявка, за да проверя за подозрение:

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

Както се оказва, има исъщо съкращение на часовата зона с име CET (което има смисъл, "CET" е съкращение). И изглежда, че PostgreSQL избира съкращението вместо пълното име. Така че, въпреки че намерих CET в имена на часовата зона , изразът '2012-01-18 1:0 CET'::timestamptz се тълкува според тънко различни правила за съкращенията на часовата зона .

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

Намирам 10 случая на съкращения на часовите зони в имена на часовата зона и не могат да разберат защо са там. Каква е целта?

Сред тях е изместването на времето (utc_offset ) не е съгласен в четири случая поради настройката за 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

В тези случаи хората може да бъдат заблудени (както аз бях), търсейки tz име и намиране на отместване на времето, което всъщност не се прилага. Това е жалък дизайн - ако не е грешка, то поне бъг в документацията .

Не мога да намеря нищо в ръководството за това как неяснотите между имена на часовите зони и съкращения са решени. Очевидно съкращенията имат предимство.

Приложение Б.1. Интерпретацията за въвеждане на дата/час споменава търсенето за съкращения на часовата зона, но остава неясно как имена на часовата зона са идентифицирани и кой от тях има приоритет в случай на двусмислен токен.

Ако токенът е текстов низ, съпоставете с възможни низове:

Направете търсене в таблица с двоично търсене за токена като съкращение на часовата зона.

Е, в това изречение има лек намек, че съкращенията са на първо място, но нищо категорично. Също така има колона abbrev и в двете таблици, pg_timezone_names и 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. Как се тълкува sql с рекурсивно изявление?

  2. Windows PSQL команден ред:има ли начин да се разреши влизане без парола?

  3. Получаване на неизвестен първичен ключ за таблица, докато идентификаторът е там

  4. Createuser:не можа да се свърже с база данни postgres:FATAL:роля tom не съществува

  5. Postgres ръчно променя последователността