PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Horodatage Postgres

Il n'y a pas de solutions à toute épreuve ici.

Mon premier conseil :ne vous fiez jamais au fuseau horaire par défaut du serveur.

Mon deuxième conseil :choisissez entre timestamp -timestamptz selon la sémantique (prédominante) des données.

Plus en détail :PostgresSQL a deux variantes d'horodatage, nommées de manière confuse TIMESTAMP WITHOUT TIMEZONE (timestamp) et TIMESTAMP WITH TIMEZONE (timestamptz) . En fait, ni l'un ni l'autre stocke un fuseau horaire, ni même un décalage. Les deux types de données occupent la même largeur (4 octets) et leur différence est subtile - et, pire, peut vous mordre si vous ne les comprenez pas parfaitement et que votre serveur modifie le fuseau horaire. Mon ensemble de règles de santé mentale est :

  • Utilisez TIMESTAMP WITH TIMEZONE (timestamptz) pour stocker les événements qui sont principalement liés au temps "physique" , pour lequel vous souhaitez principalement demander si event 1 était avant event 2 (indépendamment des fuseaux horaires), ou le calcul des intervalles de temps (en "unités physiques", par exemple, les secondes ; pas en unités "civiles" comme les jours-mois, etc.). L'exemple typique est l'heure de création/modification de l'enregistrement - ce que l'on entend généralement par le mot "Horodatage ".

  • Utiliser TIMESTAMP WITHOUT TIMEZONE (timestamp) pour stocker des événements pour lesquels l'information pertinente est l'"heure civile" (c'est-à-dire les champs {year-month-day hour-min-sec} dans son ensemble), et les requêtes impliquent des calculs calendaires. Dans ce cas, vous stockeriez ici uniquement "l'heure locale", c'est-à-dire la date-heure relative à un fuseau horaire non spécifié (non pertinent, implicite ou stocké ailleurs).

La deuxième option vous permet de rechercher plus facilement, par exemple, "tous les événements qui se sont produits le jour '2013-01-20'" (dans chaque région/pays/fuseau horaire correspondant) - mais rend plus difficile la recherche de "tous les événements qui s'est produit (physiquement) avant un événement de référence" (sauf si nous savons qu'ils se trouvent dans le même fuseau horaire). Vous choisissez.

Si vous avez besoin de tout, rien ne suffit, vous devez soit stocker le fuseau horaire, soit le décalage dans un champ supplémentaire. Une autre option, qui gaspille quelques octets mais peut être plus efficace pour les requêtes, consiste à stocker les deux champs.

Voir aussi cette réponse .