Przede wszystkim powinieneś użyć timestamptz zamiast timestamp podczas pracy z wieloma strefami czasowymi. Pozwoliłoby to całkowicie uniknąć problemu.
Szczegóły:
możesz użyj AT TIME ZONE konstrukcja taka jak @NuLo sugeruje
, może nawet działa, ale nie dokładnie tak, jak opisano.
AT TIME ZONE konwertuje typ timestamp (timestamp without time zone ) na timestamptz (timestamp with time zone ) i wzajemnie. reprezentacja tekstowa timestamp wartość zależy od bieżącego ustawienia strefy czasowej w sesji, w której uruchomiono polecenie. Te dwa timestamptz wartości są w 100% identyczne (oznaczają ten sam punkt w czasie):
'2015-09-02 15:55:00+02'::timestamptz
'2015-09-02 14:55:00+01'::timestamptz
Ale reprezentacja tekstowa nie . Wyświetlacz dotyczy różnych stref czasowych. Jeśli weźmiesz ten literał ciągu i wprowadzisz go do timestamp typ, część strefy czasowej jest po prostu ignorowana i otrzymujesz inne wartości. Dlatego jeśli uruchomisz COPY oświadczenie w sesji z tym samym ustawieniem strefy czasowej, co oryginalny timestamp wartości są dla, sugerowana operacja zdarza się do pracy.
Jednak czystym sposobem jest wygenerowanie poprawnego timestamp wartości na początek, stosując AT TIME ZONE dwa razy :
SELECT event AT TIME ZONE 'my_target_tz' AT TIME ZONE 'my_source_tz', ...
FROM logtable
ORDER BY event desc;
'my_target_tz' to "Twoja własna strefa czasowa" i 'my_source_tz' strefa czasowa serwera w chmurze w przykładzie. Aby upewnić się, że czas letni jest przestrzegany, użyj nazw stref czasowych , a nie skróty stref czasowych. Dokumentacja:
Powiązane:
- Uwzględnianie czasu letniego w Postgres podczas wybierania zaplanowanych elementów
- Nazwy stref czasowych o identycznych właściwościach dają różne wyniki po zastosowaniu do znacznika czasu
Lub, jeszcze lepiej, użyj timestamptz wszędzie i działa poprawnie automatycznie.
