Contexto:
Atualmente, executamos o PostgreSQL 8.4 em produção e estamos testando o 9.2 internamente para uma atualização futura. Algumas questões surgiram em relação às datas. Os servidores que executam 8.4 versus 9.2 são idênticos em todos os aspectos, exceto nas versões e configurações do PostgreSQL. Os mesmos dados exatos são armazenados em ambos os conjuntos de servidores; ele é transferido usando pg_dump
e pg_restore
.
Em uma parte de nosso banco de dados, armazenamos datas em um campo do tipo timestamp without time zone
.
Problema:
Ao acessar as datas desse campo, uma extract(epoch..)
requisição retorna resultados bem diferentes dependendo da versão do Postgres, assim:
#On Postgres 8.4. entered_timestamp is a "timestamp without time zone" type column:
SELECT entered_timestamp, extract(epoch from entered_timestamp) AS entered_timestamp from <table row>
entered_timestamp | entered_timestamp
----------------------------+-------------------
2012-11-01 06:01:39.699612 | 1351774899.69961
Mas...
#On Postgres 9.2. All tables, schema, and data are identical, the SELECT statement is identical to the previous one:
SELECT entered_timestamp, extract(epoch from entered_timestamp) AS entered_timestamp from <table row>
entered_timestamp | entered_timestamp
----------------------------+-------------------
2012-11-01 06:01:39.699612 | 1351749699.69961
Como você pode ver, os timestamps retornados são idênticos, mas os números de época retornados não são; na verdade, eles estão fora por várias horas. As datas do servidor e os fusos horários do Linux em ambos os servidores são idênticos (com uma diferença de um segundo). Os fusos horários do Postgres também são idênticos: a execução SELECT current_setting('timezone')
em ambos os servidores também retorna os mesmos dados. A execução SELECT now()
em ambos os servidores retorna valores quase idênticos.
Pergunta:
Como o comportamento de
extract(epoch...)
campos do tipotimestamp without time zone
mudou entre o PostgreSQL 8.4 e o PostgreSQL 9.2?Por que essa mudança ocorreu?
Existe alguma maneira de evitar essa alteração sem alterar meu esquema ou alterar dados anteriores (ou seja, uma correção baseada em configuração)?
Testando isso em minha própria máquina, obtenho 1351749699.69961 como resultado no PostgreSQL 8.4.10 e 9.2.1.
Com o PostgreSQL 8.4.10, o resultado muda de acordo com o fuso horário da sessão. Com 9.2, não.
Provavelmente este é o efeito desta mudança: meça a época do carimbo de data/hora sem fuso horário do local, não da meia-noite UTC. que é notado como uma mudança de compatibilidade 9.2.
A solução alternativa sugerida nas notas de alteração é converter o timestamp em um timestamptz primeiro: não apenas uma alteração de configuração.
Pessoalmente, acho o comportamento 9.2 mais confortável. A época do Unix é definida como UTC, então isso significa efetivamente que os valores de carimbo de data/hora simples são interpretados como UTC: que é como eu os uso de qualquer maneira.