Znacznik czasu Postgres

Nie ma tu kuloodpornych rozwiązań.

Moja pierwsza rada:nigdy nie polegaj na domyślnej strefie czasowej serwera.

Moja druga rada:wybierz między timestamp -timestamptz zgodnie z (dominującą) semantyką danych.

Bardziej szczegółowo:PostgresSQL ma dwa warianty znaczników czasu, myląco nazwane TIMESTAMP WITHOUT TIMEZONE (timestamp) i TIMESTAMP WITH TIMEZONE (timestamptz) . Właściwie ani przechowuje strefę czasową, a nawet przesunięcie. Oba typy danych zajmują tę samą szerokość (4 bajty), a ich różnica jest subtelna - i, co gorsza, mogą cię ugryźć, jeśli ich w pełni nie zrozumiesz, a serwer zmieni strefę czasową. Moje zasady dotyczące zdrowia psychicznego to:

• Użyj TIMESTAMP WITH TIMEZONE (timestamptz) do przechowywania zdarzeń związanych głównie z czasem „fizycznym” , dla którego jesteś zainteresowany głównie zapytaniem, czy event 1 było przed event 2 (niezależnie od stref czasowych) lub obliczania przedziałów czasowych (w „jednostkach fizycznych”, np. sekundach; nie w jednostkach „cywilnych” jak dni-miesiące itp.). Typowym przykładem jest czas utworzenia/modyfikacji rekordu – co zwykle oznacza słowo „znacznik czasu ".

• Użyj TIMESTAMP WITHOUT TIMEZONE (timestamp) do przechowywania wydarzeń, dla których istotną informacją jest „czas cywilny” (czyli pola {year-month-day hour-min-sec} jako całość), a zapytania wymagają obliczeń kalendarzowych. W takim przypadku zapisałbyś tutaj tylko „czas lokalny”, tj. datę i czas względem jakiejś nieokreślonej (nieistotnej, dorozumianej lub zapisanej gdzie indziej) strefy czasowej.

Druga opcja ułatwia wyszukiwanie, powiedzmy, „wszystkich wydarzeń, które miały miejsce w dniu 20.01.2013” ​​(w każdym odpowiednim regionie/kraju/strefie czasowej) – ale utrudnia wyszukiwanie „wszystkich wydarzeń, które wystąpiły (fizycznie) przed zdarzeniem referencyjnym” (chyba że wiemy, że znajdują się w tej samej strefie czasowej). Ty wybierasz.

Jeśli potrzebujesz całej rzeczy, nie wystarczy, musisz zapisać strefę czasową lub przesunięcie w dodatkowym polu. Inną opcją, która marnuje kilka bajtów, ale może być bardziej wydajna w przypadku zapytań, jest przechowywanie obu pól.

Zobacz także ta odpowiedź .