Colúmbia Britânica, Fusos Horários e Postgres
A mudança da Colúmbia Britânica para o horário de verão permanente está levando engenheiros a reexaminar como armazenam datas e horas em sistemas como o Postgres. Os comentaristas debatem se eventos futuros (como consultas médicas ou reuniões) devem ser armazenados como timestamps UTC, como hora local com um fuso horário IANA associado, ou com metadados adicionais (localização, versão do tzdata, offsets) para permanecer corretos quando as leis ou regras de DST mudarem. O consenso geral é usar bibliotecas de fuso horário testadas em batalha, tratar eventos futuros e passados de forma diferente e aceitar que nenhum esquema pode tornar o tempo futuro completamente estável quando os governos continuam reescrevendo as regras.
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.
- Armazenar data/hora local + fuso horário IANA (por exemplo,
- 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.