There are no bulletproof solutions here.
My first tip: never rely on the default time zone on the server.
My second tip: choose timestamp - timestamptz according to the (prevailing) data semantics.
In more detail: PostgresSQL has two options for timestamps, vaguely named TIMESTAMP WITHOUT TIMEZONE (timestamp) and TIMESTAMP WITH TIMEZONE (timestamptz) . In fact, neither stores the time zone, nor even the offset. Both types of data have the same width (4 bytes), and their difference is subtle - and, even worse, you can be bitten if you do not fully understand them, and your server changes the time zone. My set of health rules:
Use TIMESTAMP WITH TIMEZONE (timestamptz) to store events that are mainly related to “physical” time , for which you are mostly interested in the question of whether event 1 was before event 2 (regardless of time zones) or calculated time intervals (in " physical units ", for example, seconds, and not in" civilian "units like days-months, etc.). A typical example is the creation / modification time of a record - which usually means the word "time stamp".
Use TIMESTAMP WITHOUT TIMEZONE (timestamp) to store events for which the relevant information is “civil time” (that is, the {year-month-day hour-min-sec} fields in general) and queries include calendar calculations. In this case, you only save “local time”, that is, a date-date relative to some indefinite (irrelevant or implied or stored elsewhere) time zone.
The second option simplifies the request, say, "all events that occurred on day 2013-201-20" (in each respective region / country / time zone), but complicates the request for "all events that occurred (physically) before the control event" (if we do not know that they are in the same time zone). You choose.
If you need the complete thing, this is not enough, you need to either save the time zone or the offset in an additional field. Another option that takes a few bytes, but may be more efficient for queries, is to save both fields.
See also this answer .
leonbloy
source share