Aquí no hay soluciones a prueba de balas.
Mi primer consejo:nunca confíes en la zona horaria predeterminada del servidor.
Mi segundo consejo:elige entre timestamp
-timestamptz
según la semántica (predominante) de los datos.
Con más detalle:PostgresSQL tiene dos variantes de marca de tiempo, confusamente llamadas TIMESTAMP WITHOUT TIMEZONE (timestamp)
y TIMESTAMP WITH TIMEZONE (timestamptz)
. En realidad, ninguna almacena una zona horaria, ni siquiera un desplazamiento. Ambos tipos de datos ocupan el mismo ancho (4 bytes) y su diferencia es sutil y, lo que es peor, puede molestarlo si no los comprende completamente y su servidor cambia la zona horaria. Mi conjunto de reglas de cordura es:
-
Usa
TIMESTAMP WITH TIMEZONE (timestamptz)
para almacenar eventos que están predominantemente relacionados con el tiempo "físico" , para el cual está principalmente interesado en consultar sievent 1
fue antes delevent 2
(independientemente de las zonas horarias), o calcular intervalos de tiempo (en "unidades físicas", por ejemplo, segundos; no en unidades "civiles" como días-meses, etc.). El ejemplo típico es el tiempo de creación/modificación de registros, lo que generalmente se quiere decir con la palabra "Marca de tiempo ". -
Usar
TIMESTAMP WITHOUT TIMEZONE (timestamp)
para almacenar eventos para los cuales la información relevante es la "hora civil" (es decir, los campos{year-month-day hour-min-sec}
como un todo), y las consultas implican cálculos de calendario. En este caso, almacenaría aquí solo la "hora local", es decir, la fecha y hora relativa a alguna zona horaria no especificada (irrelevante, implícita o almacenada en otro lugar).
La segunda opción facilita la consulta de, por ejemplo, "todos los eventos que ocurrieron el día '2013-01-20'" (en cada región/país/zona horaria correspondiente), pero dificulta la consulta de "todos los eventos que ocurrido (físicamente) antes de un evento de referencia" (a menos que sepamos que están en la misma zona horaria). Tú eliges.
Si necesita todo, tampoco es suficiente, debe almacenar la zona horaria o el desplazamiento en un campo adicional. Otra opción, que desperdicia unos pocos bytes pero puede ser más eficiente para las consultas, es almacenar ambos campos.
Consulte también esta respuesta .