Différence entre les horodatages avec / sans fuseau horaire dans PostgreSQL

Les valeurs d'horodatage sont-elles stockées différemment dans PostgreSQL lorsque le type de données est WITH TIME ZONEversus WITHOUT TIME ZONE? Les différences peuvent-elles être illustrées par des cas de test simples?

Les différences sont couvertes dans la documentation PostgreSQL pour les types date / heure . Oui, le traitement de TIMEou TIMESTAMPdiffère entre l'un WITH TIME ZONEou l'autre WITHOUT TIME ZONE. Cela n'affecte pas la façon dont les valeurs sont stockées; cela affecte la manière dont ils sont interprétés.

Les effets des fuseaux horaires sur ces types de données sont traités spécifiquement dans la documentation. La différence provient de ce que le système peut raisonnablement savoir sur la valeur:

• Avec un fuseau horaire dans le cadre de la valeur, la valeur peut être rendue comme une heure locale dans le client.

• Sans un fuseau horaire dans le cadre de la valeur, le fuseau horaire par défaut évident est UTC, il est donc rendu pour ce fuseau horaire.

Le comportement diffère en fonction d'au moins trois facteurs:

• Le paramètre de fuseau horaire dans le client.
• Le type de données (c'est WITH TIME ZONE-à- dire ou WITHOUT TIME ZONE) de la valeur.
• Indique si la valeur est spécifiée avec un fuseau horaire particulier.

Voici des exemples couvrant les combinaisons de ces facteurs:

foo=> SET TIMEZONE TO 'Japan';
SET
foo=> SELECT '2011-01-01 00:00:00'::TIMESTAMP;
      timestamp      
---------------------
 2011-01-01 00:00:00
(1 row)

foo=> SELECT '2011-01-01 00:00:00'::TIMESTAMP WITH TIME ZONE;
      timestamptz       
------------------------
 2011-01-01 00:00:00+09
(1 row)

foo=> SELECT '2011-01-01 00:00:00+03'::TIMESTAMP;
      timestamp      
---------------------
 2011-01-01 00:00:00
(1 row)

foo=> SELECT '2011-01-01 00:00:00+03'::TIMESTAMP WITH TIME ZONE;
      timestamptz       
------------------------
 2011-01-01 06:00:00+09
(1 row)

foo=> SET TIMEZONE TO 'Australia/Melbourne';
SET
foo=> SELECT '2011-01-01 00:00:00'::TIMESTAMP;
      timestamp      
---------------------
 2011-01-01 00:00:00
(1 row)

foo=> SELECT '2011-01-01 00:00:00'::TIMESTAMP WITH TIME ZONE;
      timestamptz       
------------------------
 2011-01-01 00:00:00+11
(1 row)

foo=> SELECT '2011-01-01 00:00:00+03'::TIMESTAMP;
      timestamp      
---------------------
 2011-01-01 00:00:00
(1 row)

foo=> SELECT '2011-01-01 00:00:00+03'::TIMESTAMP WITH TIME ZONE;
      timestamptz       
------------------------
 2011-01-01 08:00:00+11
(1 row)

J'essaie de l'expliquer de manière plus compréhensible que la documentation PostgreSQL référencée.

Aucune des deux TIMESTAMPvariantes ne stocke un fuseau horaire (ou un décalage), malgré ce que les noms suggèrent. La différence réside dans l'interprétation des données stockées (et dans l'application prévue), et non dans le format de stockage lui-même:

• TIMESTAMP WITHOUT TIME ZONEstocke la date-heure locale (aka. date du calendrier mural et heure de l'horloge murale). Son fuseau horaire n'est pas spécifié pour autant que PostgreSQL puisse le dire (bien que votre application sache ce que c'est). Par conséquent, PostgreSQL n'effectue aucune conversion liée au fuseau horaire en entrée ou en sortie. Si la valeur a été entrée dans la base de données en tant que '2011-07-01 06:30:30', alors peu importe dans quel fuseau horaire vous l'affichez plus tard, elle indiquera toujours année 2011, mois 07, jour 01, 06 heures, 30 minutes et 30 secondes (dans un certain format). De plus, tout décalage ou fuseau horaire que vous spécifiez dans l'entrée est ignoré par PostgreSQL, donc '2011-07-01 06:30:30+00'et '2011-07-01 06:30:30+05'sont les mêmes que just '2011-07-01 06:30:30'. Pour les développeurs Java: c'est analogue à java.time.LocalDateTime.

• TIMESTAMP WITH TIME ZONEstocke un point sur la ligne horaire UTC. Son aspect (combien d'heures, de minutes, etc.) dépend de votre fuseau horaire, mais il se réfère toujours au même instant «physique» (comme le moment d'un événement physique réel). L'entrée est convertie en interne en UTC, et c'est ainsi qu'elle est stockée. Pour cela, le décalage de l'entrée doit être connu, donc lorsque l'entrée ne contient pas de décalage ou de fuseau horaire explicite (comme '2011-07-01 06:30:30'), il est supposé être dans le fuseau horaire actuel de la session PostgreSQL, sinon le décalage ou le fuseau horaire explicitement spécifié est utilisé (comme dans '2011-07-01 06:30:30+05'). La sortie est affichée convertie dans le fuseau horaire actuel de la session PostgreSQL. Pour les développeurs Java: c'est analogue à java.time.Instant(avec une résolution inférieure cependant), mais avec JDBC et JPA 2.2, vous êtes censé le mapper à java.time.OffsetDateTime(ou à java.util.Dateoujava.sql.Timestamp bien sûr).

Certains disent que les deux TIMESTAMPvariantes stockent la date et l'heure UTC. En quelque sorte, mais à mon avis, il est déroutant de le dire ainsi. TIMESTAMP WITHOUT TIME ZONEest stocké comme un TIMESTAMP WITH TIME ZONE, qui, rendu avec le fuseau horaire UTC, donne la même année, mois, jour, heures, minutes, secondes et microsecondes que dans la date-heure locale. Mais ce n'est pas censé représenter le point sur la ligne de temps que dit l'interprétation UTC, c'est juste la façon dont les champs de date-heure locaux sont codés. (C'est un groupe de points sur la ligne du temps, car le fuseau horaire réel n'est pas UTC; nous ne savons pas ce que c'est.)

Voici un exemple qui devrait vous aider. Si vous avez un horodatage avec un fuseau horaire, vous pouvez convertir cet horodatage dans n'importe quel autre fuseau horaire. Si vous n'avez pas de fuseau horaire de base, il ne sera pas converti correctement.

SELECT now(),
   now()::timestamp,
   now() AT TIME ZONE 'CST',
   now()::timestamp AT TIME ZONE 'CST'

Production:

-[ RECORD 1 ]---------------------------
now      | 2018-09-15 17:01:36.399357+03
now      | 2018-09-15 17:01:36.399357
timezone | 2018-09-15 08:01:36.399357
timezone | 2018-09-16 02:01:36.399357+03