British Columbia, fusos horários e Postgres

Armazenar datas em sistemas de agendamento exige mais do que converter horários locais para UTC. O caso da Colúmbia Britânica, que adotou permanentemente o horário de verão (UTC-7), mostra um problema clássico em bancos de dados: timestamptz não preserva a intenção local do usuário. Quando uma consulta é feita, o Postgres usa as regras atuais do fuso para converter de volta para o horário local. Se essas regras mudarem entre o cadastro e a consulta, como ocorreu com o fim do retorno ao horário padrão em Vancouver , , o horário exibido pode estar errado, mesmo que o UTC esteja correto.

A solução técnica sólida é o dual column pattern: armazenar separadamente o timestamp local, o nome do fuso (IANA) e o equivalente UTC calculado. Isso garante que a intenção original, por exemplo, 'reunião às 10h em Vancouver', permaneça imutável, enquanto o UTC é recalculado conforme as regras vigentes. Esse modelo é essencial para eventos futuros em que a hora marcada na parede é o que vale, como consultas médicas, reuniões ou prazos legais.

Muitos sistemas confiam cegamente em timestamptz pensando que estão resolvendo tudo, mas se expõem a erros silenciosos quando fusos mudam. A atualização do tzdata no Ubuntu, que acontece a cada poucos meses, pode alterar retroativamente como horários são interpretados. Sem o padrão de duas colunas, você não tem como saber se um compromisso futuro será exibido na hora certa. Isso não é teoria: já afeta dados reais em 2026. Quem opera com calendários precisa tratar o fuso como parte do dado, não como metadado descartável.