Der er ingen skudsikre løsninger her.
Mit første råd:stol aldrig på serverens standardtidszone.
Mit andet råd:vælg mellem timestamp -timestamptz i henhold til dataenes (overvejende) semantik.
Mere detaljeret:PostgresSQL har to tidsstempelvarianter, forvirrende navngivet TIMESTAMP WITHOUT TIMEZONE (timestamp) og TIMESTAMP WITH TIMEZONE (timestamptz) . Faktisk hverken gemmer en tidszone, heller ikke en offset. Begge datatyper optager den samme bredde (4 bytes), og deres forskel er subtil - og, værre, kan de bide dig, hvis du ikke helt forstår dem, og din server ændrer tidszonen. Mit fornuftsregler er:
-
Brug
TIMESTAMP WITH TIMEZONE (timestamptz)til lagring af begivenheder, der overvejende er relateret til den "fysiske" tid , som du primært er interesseret i at spørge omevent 1var førevent 2(uanset tidszoner) eller beregningstidsintervaller (i "fysiske enheder", f.eks. sekunder; ikke i "civile" enheder som dage-måneder osv.). Det typiske eksempel er registrerings-oprettelse/ændringstid - hvad man normalt mener med ordet "tidsstempel ". -
Brug
TIMESTAMP WITHOUT TIMEZONE (timestamp)til lagring af begivenheder, hvor de relevante oplysninger er "borgerlige tider" (det vil sige felterne{year-month-day hour-min-sec}som helhed), og forespørgslerne involverer kalenderberegninger. I dette tilfælde vil du kun gemme den "lokale tid", dvs. dato-klokkeslæt i forhold til en uspecificeret (irrelevant eller underforstået eller gemt et andet sted) tidszone.
Den anden mulighed gør dig nemmere at forespørge efter f.eks. "alle hændelser, der skete på dagen '2013-01-20'" (i hver tilsvarende region/land/tidszone) - men gør det sværere at forespørge efter "alle hændelser, der opstod (fysisk) før en referencehændelse" (medmindre vi ved, at de er i samme tidszone). Du vælger.
Hvis du har brug for det fulde, er det heller ikke nok, du skal enten gemme tidszonen eller forskydningen i et ekstra felt. En anden mulighed, som spilder nogle få bytes, men som kan være mere effektiv til forespørgsler, er at gemme begge felter.
Se også dette svar .