Kiedy zapisujesz timestamp with time zone (timestamptz ) jest konwertowany na czas UTC w celu przechowywania w bazie danych. Po pobraniu jest konwertowany na bieżącą strefę czasową klienta, a nie strefę czasową, w której był pierwotnie. Zasadniczo jest to punkt w czasie.
Istnieje również timestamp without time zone (timestamptz ). Nie podlega konwersji, ale nie nosić przy sobie znacznik czasu. Jeśli przechowujesz timestamp ze strefą czasową klienta ustawioną na UTC, a następnie pobierz ją, gdy strefa czasowa klienta to „+08:00”, otrzymasz tę samą wartość. To połowa tego, czego chcesz, ponieważ zachowuje surową wartość czasu.
Nazwy i zachowania są okropne i mylące, ale określone przez standard SQL.
Strefę czasową należy zapisać oddzielnie, jeśli chcesz zarejestrować punkt w określonej strefie czasowej. Zalecam przechowywanie go jako INTERVAL z CHECK ograniczenie ograniczające ją do colname BETWEEN INTERVAL '-12' HOUR + INTERVAL '1' SECOND AND INTERVAL '12' HOUR . Ta definicja odrzuca -12:00 i akceptuje +12:00; Nie jestem do końca pewien, czy to prawda, więc sprawdź.
Możesz przechowywać timestamp czasu lokalnego w tej strefie czasowej (co prawdopodobnie bym zrobił) lub przechowywać timestamptz czasu UTC, w którym wystąpiło zdarzenie, plus przesunięcie, które pozwala przekonwertować je na czas lokalny.
Albo będzie działać dobrze dla JDBC. W przypadku JPA będzie to zależeć od tego, jak dobrze Twój dostawca rozumie i mapuje typy interwałów. Idealnie potrzebujesz pola wygenerowanego w sposób przejściowy w swojej encji, które rekonstruuje żądaną instancję Kalendarza przy użyciu timestamp i interval przechowywane w bazie danych.
