Em primeiro lugar, você deve usar
timestamptz em vez de timestamp sempre que trabalhar com vários fusos horários. Evitaria completamente o problema. Detalhes:
Você pode use o
AT TIME ZONE construir como @NuLo sugere
, ele pode mesmo funcionar, mas não exatamente como descrito. AT TIME ZONE converte o tipo timestamp (timestamp without time zone ) para timestamptz (timestamp with time zone ) e vice versa. A representação de texto de um timestamptz o valor depende da configuração atual do fuso horário na sessão em que você executa o comando. Esses dois timestamptz valores são 100% idênticos (indicam o mesmo ponto no tempo):'2015-09-02 15:55:00+02'::timestamptz
'2015-09-02 14:55:00+01'::timestamptz
Mas a representação de texto não . A exibição é para diferentes fusos horários. Se você pegar essa string literal e alimentá-la para um
timestamp tipo, a parte do fuso horário é apenas ignorada e você acaba com diferentes valores. Portanto, se você executar seu COPY declaração em uma sessão com a mesma configuração de fuso horário que seu timestamp original os valores são para, a operação sugerida acontece trabalhar. A maneira limpa, no entanto, é produzir o
timestamp correto valores para começar aplicando AT TIME ZONE duas vezes :SELECT event AT TIME ZONE 'my_target_tz' AT TIME ZONE 'my_source_tz', ...
FROM logtable
ORDER BY event desc;'my_target_tz' é "seu próprio fuso horário" e 'my_source_tz' o fuso horário do servidor em nuvem no exemplo. Para garantir que o horário de verão seja respeitado, use nomes de fuso horário , não abreviações de fuso horário. A documentação:
Relacionado:
- Contabilizando o horário de verão no Postgres, ao selecionar itens agendados
- Nomes de fuso horário com propriedades idênticas geram resultados diferentes quando aplicados ao carimbo de data/hora
Ou, melhor ainda, use
timestamptz em todos os lugares e funciona corretamente automaticamente. 
