Тук няма бронирани решения.
Първият ми съвет:никога не разчитайте на часовата зона по подразбиране на сървъра.
Вторият ми съвет:изберете между timestamp -timestamptz според (преобладаващата) семантика на данните.
По-подробно:PostgresSQL има два варианта на времево клеймо, объркващо наречени TIMESTAMP WITHOUT TIMEZONE (timestamp) и TIMESTAMP WITH TIMEZONE (timestamptz) . Всъщност нитото съхранява часова зона, нито дори отместване. И двата типа данни заемат една и съща ширина (4 байта) и разликата им е фина - и, което е по-лошо, може да ви ухапе, ако не ги разбирате напълно и сървърът ви промени часовата зона. Моят набор от правила за разум е:
-
Използвайте
TIMESTAMP WITH TIMEZONE (timestamptz)за съхраняване на събития, които са предимно свързани с "физическото" време , за което се интересувате главно от запитване далиevent 1беше предиevent 2(независимо от часовите зони) или изчисляване на времеви интервали (във „физически единици“, напр. секунди; не в „граждански“ единици като дни-месеци и т.н.). Типичният пример е времето за създаване/модифициране на запис - това, което обикновено се има предвид под думата „Клеймо за време ". -
Използвайте
TIMESTAMP WITHOUT TIMEZONE (timestamp)за съхраняване на събития, за които съответната информация е "гражданското време" (т.е. полетата{year-month-day hour-min-sec}като цяло), а заявките включват календарни изчисления. В този случай ще съхраните тук само „местното време“, т.е. дата-час спрямо някаква неуточнена (неуместна, или подразбираща се, или съхранена някъде другаде) часова зона.
Втората опция ви улеснява да търсите, да речем, „всички събития, случили се на ден „2013-01-20“ (във всеки съответен регион/държава/часова зона) – но прави по-трудно запитването за „всички събития, които настъпили (физически) преди референтно събитие" (освен ако не знаем, че са в една и съща часова зона). Вие избирате.
Ако имате нужда от всичко, нито едно от двете не е достатъчно, трябва или да съхраните часовата зона, или отместването в допълнително поле. Друга опция, която губи няколко байта, но може да бъде по-ефективна за заявки, е да съхранявате и двете полета.
Вижте също този отговор .
