Colúmbia Britânica adota fuso horário fixo em 2026: risco para aplicações que usam UTC no PostgreSQL

A mudança na Colúmbia Britânica não é só política: é um teste de resistência para sistemas que assumem estabilidade nas regras de fuso horário. O PostgreSQL armazena timestamptz como UTC, mas converte *na hora da gravação* usando as regras do tzdata vigentes então. Se um agendamento foi feito em janeiro de 2026 com o fuso antigo (UTC-8 no inverno), e o tzdata foi atualizado em abril, a consulta em novembro devolve 11h local em vez de 10h. Isso não é bug: é comportamento esperado. O problema real está na arquitetura, confiar em conversão implícita de timestamptz ignora que intenção humana (‘10h em Vancouver’) é imutável; regra de fuso horário não é.

O padrão de dupla coluna, local_time + timezone_name, não é overengineering. É defesa contra falha de domínio: assim como regiões de cloud deixaram de ser isoladas por sanções ou cortes de cabos (como mostramos em 27/04), fusos horários deixaram de ser estáveis por decisões legislativas. Armazenar o nome IANA (ex: America/Vancouver) em vez de um offset fixo (ex: -07:00) permite reaplicar a lógica correta mesmo quando as regras mudam, desde que você tenha o dado explícito da intenção original.

A cobertura CEVIU anterior não tratou fusos horários, mas a lição aqui ecoa diretamente o alerta de 02/06 sobre casos de borda negligenciados: desvios de uma hora parecem marginais até afetarem milhares de agendamentos médicos ou entregas logísticas. Em abril, destacamos como cenários extremos ressurgem com força, e essa mudança é exatamente isso: um caso de borda que virou regra regional. Diferente de 2025, quando discussões sobre RFC 9557 eram teóricas, agora há um evento concreto exigindo ação imediata em produção, e o padrão de dupla coluna deixou de ser recomendação acadêmica para exigência operacional.

Aplicações brasileiras que atendem clientes canadenses, ou usam infraestrutura hospedada lá, já estão expostas. Um sistema de telemedicina com backend no Canadá, por exemplo, pode notificar paciente às 9h local pensando que é 10h, gerando falha de adesão. Mais grave: se o tzdata estiver desatualizado em um cluster Kubernetes no GCP Vancouver, a discrepância entre nós pode causar inconsistências em jobs agendados via pg_cron. Isso não é só sobre correção de hora, é sobre garantir que o contrato temporal entre usuário e sistema permaneça válido, mesmo quando governos reescrevem o tempo.