Dans Postgres 9.5, j'ai été surpris de voir le résultat ci-dessous en expérimentant l'année 0001
(pas l'année zéro 0000
).
Décalage de -07:52:58
?
Un exemple de code. Notez que j'ai mélangé l'utilisation de TIMESTAMP WITH TIME ZONE
et TIMESTAMP WITHOUT TIME ZONE
, alors lisez attentivement.
SET TIME ZONE 'America/Los_Angeles' ;
SELECT (TIMESTAMP WITH TIME ZONE '2015-01-01 00:00:00.0',
TIMESTAMP WITH TIME ZONE '0001-01-01 00:00:00.0Z',
TIMESTAMP WITHOUT TIME ZONE '0001-01-01 00:00:00.0Z') ;
("2015-01-01 00:00:00-08","0001-12-31 16:07:02-07:52:58 BC","0001-01-01 00:00:00")
Je suis surpris par cette deuxième valeur: 0001-12-31 16:07:02-07:52:58 BC
. Je comprends que nous devons reculer de huit heures, comme America/Los_Angeles
huit heures derrière UTC avec un décalage de -08:00
. Mais au lieu du -08:00
décalage est -07:52:58
. Pourquoi?
Aucun problème sous UTC
Aucun problème de ce type lors de la saisie de données sous UTC.
SET TIME ZONE 'UTC' ;
SELECT (TIMESTAMP WITH TIME ZONE '2015-01-01 00:00:00.0',
TIMESTAMP WITH TIME ZONE '0001-01-01 00:00:00.0Z',
TIMESTAMP WITHOUT TIME ZONE '0001-01-01 00:00:00.0Z');
("2015-01-01 00:00:00+00","0001-01-01 00:00:00+00","0001-01-01 00:00:00")
Aucune année zéro
Soit dit en passant, la partie date semble être correcte. Il semble qu'il n'y ait pas d'année 0000
, celle-là étant le pivot entre les époques «BC» et «AD». Prenez le premier moment de l'année 0001, soustrayez une heure, et vous obtenez l'année 0001 BC
- donc pas d'année zéro.
SET TIME ZONE 'UTC' ;
INSERT INTO moment_ -- TIMESTAMP WITH TIME ZONE.
VALUES ( TIMESTAMP '0001-01-01 00:00:00.0Z' - INTERVAL '1 hour' ) ;
SET TIME ZONE 'UTC' ;
TABLE moment_ ;
Le résultat est l'année 0001 BC
, nous sautons donc de 0001
à 0001 BC
; pas d'année zéro 0000
.
"0001-12-31 23:00:00+00 BC"
la source
0000
comme valeur d'année valide mais sans insister sur le fait qu'il soit utilisé ou non. ). Il est vrai que PostgreSQL utilise le formulaire sans année 0, mais vous ne pouvez pas dire "les années commencent un 1, pas 0" comme si c'était une sorte de fait universel. Il est facile de traduire entre eux pour, par exemple, des données astronomiques. (Le troisième millénaire a toujours commencé en 2001 dans les deux cas, car il est resté le troisième millénaire depuis le 1er CE)Réponses:
Le 18 novembre 1883 à 12h00 (nouvelle heure), l'heure standard a été adoptée par les chemins de fer américains.
Cela signifie qu'avant cette date, Los Angeles utilisait l'heure locale réelle, basée sur l'heure solaire moyenne. Après cela, il a été déplacé vers son fuseau horaire local, qui, étant un décalage intégral des heures par rapport à l'heure moyenne de Greenwich, était légèrement différent de l'heure précédente.
Vouloir en savoir davantage?
Téléchargez la base de données de fuseau horaire tzdata depuis IANA: Fuseaux horaires .
À l'intérieur, vous trouverez les définitions des (nombreux) fuseaux horaires, qui ont beaucoup de variations au fil du temps, ainsi que de nombreux commentaires détaillant les changements où et quand. C'est une lecture divertissante!
Wikipédia a également quelques faits intéressants, dans la page Wikipédia: Fuseau horaire , concernant le changement du 18 novembre 1883:
Notez également que cela n'est pas spécifique à Postgresql. Ceci est valable pour tout logiciel ou système d'exploitation qui utilise la base de données tzdata (même si bien sûr, beaucoup seront limités aux dates post 1970 ou post 1901, donc 1883 est hors de portée, mais il y a beaucoup, beaucoup d'autres ajustements partout dans le monde à des moments différents).
la source