Wir debattieren über die beste Möglichkeit, einen Zeitstempel in Postgres zu speichern. Derzeit sind alle Zeitstempel als +00 gespeichert und wir haben mit jedem Client eine Zeitzone verbunden. Wir suchen die Zeitzone auf und konvertieren die Zeit, in der etwas passiert ist, was die Komplexität erhöht, da wir mehr Joins und eine komplexere Abfrage durchführen müssen.
Eine andere Methode besteht darin, eine Verbindung zu Postgres herzustellen und die Zeitzone der Verbindung einzustellen. Sie ändert sich so oft wie diese Zeitzone.
Mein Problem ist, dass es in ANZ 4-5 Zeitzonen gibt. Wenn wir versuchen, unsere Rechnungen zu erstellen, müssen wir wissen, an welchem Tag bestimmte Transaktionen stattgefunden haben, und in drei Zeitzonen gibt es keine perfekte Lösung.
Ich dachte daran, die Zeitzone in den Zeitstempel aufzunehmen, um es einfacher zu machen - TIMESTAMP '1999-01-15 8:00:00 -8: 00'
Ich hatte den Eindruck, dass dies die beste Vorgehensweise ist, aber einige Leute sagen, dass dies eine schlechte Idee ist. Wir werden Kunden in ganz ANZ haben, für die wir genaue Rechnungen erstellen müssen. Was ist die beste und eleganteste Lösung?
Prost Scott
Hier gibt es keine kugelsicheren Lösungen.
Mein erster Rat: Verlassen Sie sich niemals auf die Standardzeitzone des Servers.
Mein zweiter Tipp: Wählen Sie zwischen timestamp - timestamptz entsprechend der (vorherrschenden) Semantik der Daten.
Ausführlicher:
PostgresSQL hat zwei Timestamp-Varianten, die verwirrenderweise TIMESTAMP WITHOUT TIMEZONE (timestamp) und TIMESTAMP WITH TIMEZONE (timestamptz) heißen. Tatsächlich speichert weder eine Zeitzone noch einen Offset. Beide Datentypen haben die gleiche Breite (4 Bytes) und ihr Unterschied ist subtil - und schlimmer noch, sie können Sie beißen, wenn Sie sie nicht vollständig verstehen und Ihr Server die Zeitzone ändert. Mein Gesundheitsregelsatz ist:
Verwenden Sie TIMESTAMP WITH TIMEZONE (timestamptz) zum Speichern von Ereignissen, die sich hauptsächlich auf die "physische" Zeit beziehen , an der Sie hauptsächlich interessiert sind, ob event 1 war vor event 2 (unabhängig von Zeitzonen) oder Rechenzeitintervallen (in "physikalischen Einheiten", z. B. Sekunden; nicht in "zivilen" Einheiten wie Tag-Monat usw.). Das typische Beispiel ist die Zeit für die Erstellung / Änderung von Datensätzen - was man normalerweise mit dem Wort " Timestamp " meint.
Verwenden Sie TIMESTAMP WITHOUT TIMEZONE (timestamp) zum Speichern von Ereignissen, für die die relevante Information die "zivile Zeit" ist (dh die Felder {year-month-day hour-min-sec} als Ganzes) ), und die Abfragen beinhalten Kalenderberechnungen. In diesem Fall würden Sie hier nur die "lokale Zeit" speichern, d. H. Das Datum-Uhrzeit-Verhältnis in Bezug auf eine nicht angegebene (irrelevante oder implizite oder irgendwo anders gespeicherte) Zeitzone.
Die zweite Option erleichtert die Abfrage von beispielsweise "alle Ereignisse, die am Tag 2013-01-20 stattgefunden haben" (in jeder entsprechenden Region / jedem Land / jeder Zeitzone) - macht es jedoch schwieriger, nach " alle Ereignisse, die (physisch) vor einem Referenzereignis aufgetreten sind "(es sei denn, wir wissen, dass sie sich in derselben Zeitzone befinden). Sie wählen.
Wenn Sie das vollständige Ding brauchen, ist beides nicht genug, Sie müssen entweder die Zeitzone oder den Offset in einem zusätzlichen Feld speichern. Eine andere Option, die einige Bytes verschwendet, aber für Abfragen effizienter sein kann, ist das Speichern beider Felder.
Siehe auch diese Antwort .
Verwenden Sie timestamptz (oder timestamp with time zone für die Standard-SQL-Syntax) für In Ihren Eingabefeldern können Sie dann einen benutzerdefinierten Zeitversatz für jede Einfügung festlegen, indem Sie entweder die Zeitzone oder den Zeitversatz verwenden, die Ihren Wünschen entsprechen.
Beispiel ...
%Vor%... und deine Zeiten werden entsprechend angepasst
%Vor%oder noch besser, versuchen Sie Folgendes ...
%Vor%Um eine Vorstellung von der Liste der Zeitzonen zu bekommen, die in Ihrer Datenbank verfügbar sind, versuchen Sie es mit:
%Vor%Tags und Links database postgresql timezone timestamp