Armadilhas do datetime em Python, e o que as bibliotecas estão (ou não estão) fazendo a respeito

Artigo original ↗ Discussão no Hacker News ↗

Lidar com datas e horas em software acaba sendo muito mais complexo do que “basta usar UTC”, especialmente quando entram horário de verão, leis de fuso horário que mudam e eventos futuros voltados para humanos, como reuniões ou contratos. Comentadores debatem como o módulo `datetime` do Python e alternativas deveriam representar o tempo — instantes UTC, horários locais do “relógio de parede”, offsets fixos ou fusos IANA completos — e se bibliotecas deveriam permitir tempos ambíguos ou inexistentes. Muitos concluem que nenhum modelo único serve para todos os casos de uso, então bibliotecas robustas precisam de vários tipos explícitos e trade-offs claros, em vez de uma abstração mágica única de timestamp.

UTC vs horário local e datetimes futuros

  • Muitos argumentam que “armazenar tudo em UTC” funciona bem para eventos passados e timestamps centrados na máquina.
  • Outros enfatizam que isso falha para horários futuros agendados por humanos (reuniões, compromissos, contratos).
  • Ponto-chave: horários futuros no relógio local geralmente devem ser armazenados como (datetime local + fuso horário IANA), e não pré-convertidos para UTC, porque as regras de fuso horário/DST podem mudar.
  • Não existe uma regra universal: às vezes os usuários querem um instante UTC fixo, às vezes “hora local” em um lugar.

DST, fusos horários e expectativas humanas

  • DST e políticas de fuso horário são políticas e mutáveis; não é possível prever regras futuras.
  • Eventos recorrentes (“toda segunda às 10:00”, “1:1 a cada duas semanas às 13h”) não devem mudar uma hora ao atravessar o DST; isso exige modelar explicitamente o horário local e os fusos.
  • Reuniões entre continentes sofrem desalinhamento temporário quando as transições de DST ocorrem em datas diferentes; calendários normalmente escolhem um fuso de referência.

Formatos de dados e épocas (ISO 8601, Unix time etc.)

  • ISO 8601 / RFC 3339 ajudam com formatação de strings, mas não resolvem semântica de fuso horário/DST nem localização.
  • Formatos no estilo americano MM/DD/YYYY e ferramentas como o Excel são vistos como grandes fontes de bugs.
  • Segundos desde a época Unix (ou micros/nanosegundos inteiros) são populares para representação interna, mas o suporte a datas anteriores a 1970 e segundos bissextos é complicado.

Segundos bissextos

  • Algumas bibliotecas (por exemplo, de uso geral, incluindo as discutidas) ignoram segundos bissextos; outras especializadas (por exemplo, focadas em astronomia) lidam com eles.
  • As opiniões divergem: alguns consideram aceitável ignorar segundos bissextos para a maioria dos aplicativos; outros observam que isso quebra cálculos precisos de duração/instante e o parsing de “23:59:60”.

Design de bibliotecas: tipos e comportamento

  • Forte समर्थन para tipos distintos:
    • Instant/UTC-only,
    • ZonedDateTime (fusos IANA),
    • OffsetDateTime (offset fixo),
    • date-times locais/naive para casos de uso de relógio local ou recorrência.
  • Combinar dados naive e com fuso em um único tipo (como em algumas bibliotecas de JS e Python) é amplamente criticado.
  • Debate sobre representar horários inexistentes durante lacunas de DST:
    • Alguns preferem proibir ou gerar erro para horários locais inválidos.
    • Outros preferem mapeamentos “best-effort” documentados e determinísticos, mesmo que surpreendentes.

Conceito de “horário local”

  • Alguns argumentam que o “horário local” do sistema é um erro histórico, exceto para UI e compatibilidade com libc; melhor seria sempre especificar fusos horários ou localidades explicitamente.
  • Outros observam que usuários e dispositivos comuns ainda precisam de uma noção de hora local do relógio para alarmes, tarefas estilo cron e semânticas como “às 16h no café”.