Allereerst moet u timestamptz
. gebruiken in plaats van timestamp
wanneer u met meerdere tijdzones werkt. Zou het probleem volledig vermijden.
Details:
Je kunt gebruik de AT TIME ZONE
construeren zoals @NuLo suggereert
, het mag werken zelfs, maar niet precies zoals beschreven.
AT TIME ZONE
converteert het type timestamp
(timestamp without time zone
) naar timestamptz
(timestamp with time zone
) en vice versa. De tekstweergave van een timestamptz
waarde hangt af van de huidige instelling van de tijdzone in de sessie waarin u de opdracht uitvoert. Deze twee timestamptz
waarden zijn 100 % identiek (duiden hetzelfde tijdstip aan):
'2015-09-02 15:55:00+02'::timestamptz
'2015-09-02 14:55:00+01'::timestamptz
Maar de tekstweergave is niet . Het display is voor verschillende tijdzones. Als u deze tekenreeks letterlijk neemt en deze invoert in een timestamp
type, het tijdzonegedeelte wordt gewoon genegeerd en je eindigt met anders waarden. Dus als u uw COPY
verklaring in een sessie met dezelfde tijdzone-instelling als uw originele timestamp
waarden zijn voor, de voorgestelde bewerking gebeurt aan het werk.
De schone manier is echter om de juiste timestamp
te produceren waarden om mee te beginnen door AT TIME ZONE
. toe te passen tweemaal :
SELECT event AT TIME ZONE 'my_target_tz' AT TIME ZONE 'my_source_tz', ...
FROM logtable
ORDER BY event desc;
'my_target_tz'
is "uw eigen tijdzone" en 'my_source_tz'
de tijdzone van de cloudserver in het voorbeeld. Om ervoor te zorgen dat de zomertijd wordt gerespecteerd, gebruikt u tijdzonenamen , geen afkortingen voor tijdzones. De documentatie:
Gerelateerd:
- Rekening houden met DST in Postgres, bij het selecteren van geplande items
- Tijdzonenamen met identieke eigenschappen leveren verschillende resultaten op wanneer toegepast op tijdstempel
Of, nog veel beter, gebruik timestamptz
overal en het werkt automatisch correct.