Als erstes sollten Sie timestamptz verwenden statt timestamp wenn Sie mit mehreren Zeitzonen arbeiten. Würde das Problem komplett vermeiden.
Einzelheiten:
Sie können Verwenden Sie den AT TIME ZONE Konstrukt wie @NuLo vorschlägt
, es kann sogar funktionieren, aber nicht genau wie beschrieben.
AT TIME ZONE konvertiert den Typ timestamp (timestamp without time zone ) zu timestamptz (timestamp with time zone ) und umgekehrt. Die Textdarstellung eines timestamptz Wert hängt von der aktuellen Einstellung ab der Zeitzone in der Sitzung, in der Sie den Befehl ausführen. Diese beiden timestamptz Werte sind zu 100 % identisch (bezeichnen denselben Zeitpunkt):
'2015-09-02 15:55:00+02'::timestamptz
'2015-09-02 14:55:00+01'::timestamptz
Aber die Textdarstellung ist nicht . Die Anzeige erfolgt für verschiedene Zeitzonen. Wenn Sie dieses String-Literal nehmen und es einem timestamp zuführen Typ wird der Zeitzonenteil einfach ignoriert und am Ende erhalten Sie anders Werte. Wenn Sie also Ihr COPY ausführen -Anweisung in einer Sitzung mit derselben Zeitzoneneinstellung wie Ihr ursprünglicher timestamp Werte sind für, die vorgeschlagene Operation passiert zu arbeiten.
Der saubere Weg ist jedoch, den korrekten timestamp zu erzeugen Werte zunächst durch Anwenden von AT TIME ZONE zweimal :
SELECT event AT TIME ZONE 'my_target_tz' AT TIME ZONE 'my_source_tz', ...
FROM logtable
ORDER BY event desc;
'my_target_tz' ist "Ihre eigene Zeitzone" und 'my_source_tz' im Beispiel die Zeitzone des Cloud-Servers. Verwenden Sie Zeitzonennamen, um sicherzustellen, dass die Sommerzeit eingehalten wird , keine Abkürzungen für Zeitzonen. Die Dokumentation:
Verwandte:
- Berücksichtigung der Sommerzeit in Postgres bei der Auswahl geplanter Elemente
- Zeitzonennamen mit identischen Eigenschaften führen zu unterschiedlichen Ergebnissen, wenn sie auf den Zeitstempel angewendet werden
Oder, noch viel besser, verwenden Sie timestamptz überall und es funktioniert automatisch korrekt.
