Niestety PostgreSQL nie oferuje typu danych strefy czasowej, więc prawdopodobnie powinieneś użyć text .
interval na pierwszy rzut oka wydaje się logiczną opcją i jest odpowiednie do niektórych zastosowań. Jednak nie uwzględnia czasu letniego ani faktu, że różne regiony w tym samym przesunięciu UTC mają różne reguły czasu letniego.
Nie ma mapowania 1:1 z przesunięcia czasu UTC z powrotem do strefy czasowej.
Na przykład strefa czasowa Australia/Sydney (Nowa Południowa Walia) to UTC+10 (EST ) lub UTC+11 (EDT ) w czasie letnim. Tak, to ten sam akronim EST używane przez USA; akronimy stref czasowych nie są unikalne w bazie danych tzdata, dlatego Pg ma timezone_abbreviations ustawienie. Co gorsza, Brisbane (Queensland) znajduje się na prawie tej samej długości geograficznej i jest w UTC+10 EST ... ale nie ma czasu letniego, więc czasami jest na poziomie -1 przesunięcie do Nowej Południowej Walii podczas czasu letniego w NSW.
(Aktualizacja :Niedawno Australia przyjęła A prefiks, więc używa AEST jako jego wschodnie stany akronim TZ, ale EST i WST pozostają w powszechnym użyciu).
Dużo się mylisz?
Jeśli wszystko, co musisz przechowywać, to przesunięcie UTC następnie interval jest odpowiednie. Jeśli chcesz zapisać strefę czasową , zapisz go jako text . W tej chwili trudno jest sprawdzić poprawność i przekonwertować na przesunięcie strefy czasowej, ale przynajmniej radzi sobie z czasem letnim.
