Juste après avoir posté ceci, j'ai exécuté une autre requête pour vérifier un soupçon :
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
Il s'avère qu'il y a aussi une abréviation de fuseau horaire nommé CET (ce qui est logique, "CET" étant une abréviation). Et il semble que PostgreSQL choisit l'abréviation sur le nom complet. Donc, même si j'ai trouvé CET dans le fuseau horaire noms , l'expression '2012-01-18 1:0 CET' ::timestamptz est interprétée selon les règles subtilement différentes pour les abréviations de fuseau horaire .
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
Je trouve 10 cas d'abréviations de fuseau horaire dans le fuseau horaire noms et ne comprennent pas pourquoi ceux-ci sont là. Quel est le but ?
Parmi ceux-ci, le décalage horaire (utc_offset ) n'est pas d'accord dans quatre cas en raison du paramètre 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
Dans ces cas, les gens peuvent être trompés (comme moi) en cherchant le nom tz et trouver un décalage temporel qui n'est pas réellement appliqué. C'est une conception malheureuse - sinon un bogue, au moins un bogue de documentation .
Je ne trouve rien dans le manuel sur la façon dont les ambiguïtés entre les noms de fuseau horaire et abréviations sont résolus. Évidemment, les abréviations priment.
Annexe B.1. L'interprétation de la saisie de date/heure mentionne la recherche d'abréviations de fuseau horaire, mais cela reste pas clair comment les noms des fuseaux horaires sont identifiés et lequel d'entre eux est prioritaire en cas de jeton ambigu.
Si le jeton est une chaîne de texte, faites correspondre les chaînes possibles :
Effectuez une recherche binaire dans la table de recherche pour le jeton en tant qu'abréviation de fuseau horaire.
Eh bien, il y a un léger indice dans cette phrase que les abréviations viennent en premier, mais rien de définitif. De plus, il y a une colonne abbrev dans les deux tables, pg_timezone_names et pg_timezone_abbrevs ...
