Não há soluções à prova de balas aqui.

Meu primeiro conselho:nunca confie no fuso horário padrão do servidor.

Meu segundo conselho:escolha entre timestamp -timestamptz de acordo com a semântica (predominante) dos dados.

Em mais detalhes:PostgresSQL tem duas variantes de timestamp, nomeadas confusamente TIMESTAMP WITHOUT TIMEZONE (timestamp) e TIMESTAMP WITH TIMEZONE (timestamptz) . Na verdade, nenhum armazena um fuso horário, nem mesmo um deslocamento. Ambos os tipos de dados ocupam a mesma largura (4 bytes), e sua diferença é sutil - e, pior, pode mordê-lo se você não os entender completamente e seu servidor alterar o fuso horário. Meu conjunto de regras de sanidade é:

• 
  Use TIMESTAMP WITH TIMEZONE (timestamptz) para armazenar eventos predominantemente relacionados ao tempo "físico" , para o qual você está interessado principalmente em consultar se o event 1 foi antes do event 2 (independentemente de fusos horários), ou intervalos de tempo de computação (em "unidades físicas", por exemplo, segundos; não em unidades "civis" como dias-meses, etc). O exemplo típico é o tempo de criação/modificação de registro - o que normalmente significa a palavra "Timestamp ".
  
• 
  Use TIMESTAMP WITHOUT TIMEZONE (timestamp) para armazenar eventos para os quais as informações relevantes são o "horário civil" (ou seja, os campos {year-month-day hour-min-sec} como um todo), e as consultas envolvem cálculos de calendário. Nesse caso, você armazenaria aqui apenas a "hora local", ou seja, a data e hora relativa a algum fuso horário não especificado (irrelevante, implícito ou armazenado em outro lugar).
  

A segunda opção facilita a consulta de, digamos, "todos os eventos que aconteceram no dia '2013-01-20'" (em cada região/país/fuso horário correspondente) - mas dificulta a consulta de "todos os eventos que ocorreu (fisicamente) antes de um evento de referência" (a menos que saibamos que eles estão no mesmo fuso horário). Você escolhe.

Se você precisa da coisa completa, nenhum deles é suficiente, você precisa armazenar o fuso horário ou o deslocamento em um campo adicional. Outra opção, que desperdiça alguns bytes, mas pode ser mais eficiente para consultas, é armazenar os dois campos.

Veja também esta resposta .