Colúmbia Britânica, Fusos Horários e Postgres

Artigo original ↗ Discussão no Hacker News ↗

Armazenar timestamps: UTC vs hora local

  • Forte discordância sobre “sempre armazenar em UTC”.
  • Um lado diz: armazene apenas timestamps Unix em UTC como fonte da verdade; converta com bibliotecas confiáveis; fusos horários são complexos demais para lidar manualmente.
  • Outros argumentam que isso é um “erro comum” quando o horário no relógio de parede importa (consultas, marcações de ponto, horário de expediente). A hora local existe independentemente do UTC e muitas vezes deve ser armazenada diretamente.
  • Alguns enfatizam que UTC é apropriado para instantes literais (logs, eventos que já ocorreram), não para conceitos de domínio ligados a relógios locais.

Eventos futuros e mudanças de fuso horário (caso da BC)

  • Questão central: uma consulta futura marcada como “14h no horário local” pode corresponder a um instante UTC diferente se as leis mudarem (por exemplo, a Colúmbia Britânica passando para horário de verão permanente).
  • Isso força uma escolha de referência “autoritativa”:
    • A hora local no local do evento, ou
    • O instante UTC calculado originalmente, ou
    • A hora local de outro participante em reuniões em múltiplos fusos.
  • Vários comentaristas enfatizam que qualquer representação de eventos futuros é inerentemente provisória; governos e fronteiras podem mudar.

Estratégias de esquema e modelagem

  • Abordagens propostas para eventos futuros:
    • Armazenar data/hora local + fuso horário IANA (por exemplo, America/Vancouver), opcionalmente junto com a localização.
    • Para consultas, usar DATE/TIME ou TIMESTAMP sem timezone para a hora local; converter apenas na camada de apresentação.
    • Manter um instante UTC adicional para consultas/otimização, mas marcar claramente qual campo é o autoritativo.
  • Para eventos passados: muitos sugerem UTC, com timezone apenas quando a hora local no relógio tem importância semântica (por exemplo, ponto eletrônico, análise histórica).
  • Alguns sugerem armazenar offsets de timezone e/ou a versão do tzdata ou o momento da inserção para reconstruir a intenção quando regras ou dados mudam.

Bibliotecas, tzdata e complexidade

  • Consenso: nunca reimplementar lógica de fuso horário; confiar em bibliotecas baseadas em tzdata.
  • No entanto, o próprio tzdata muda com frequência para timestamps passados e futuros, e pode conter erros históricos.
  • Ideias levantadas: sistemas que rastreiam versões do tzdata por registro, ou usam estratégias semelhantes a bitemporal para “o que acreditávamos naquele momento”.

DST, política e reação na BC

  • Muitos criticam o DST em geral e preferem horário permanente, mas discordam sobre se o horário padrão permanente ou o horário de verão permanente é mais saudável.
  • A decisão da Colúmbia Britânica de adotar horário de verão permanente é controversa; alguns moradores gostam de acabar com as mudanças de relógio, outros argumentam que a consulta foi enganosa e que o horário padrão seria melhor.