Ask HN: Você encontrou algum bug de ano bissexto hoje?

Falhas reais e problemas operacionais

• Vários sistemas de pagamento falharam:
  • Uma grande cadeia sueca de supermercados e bombas de combustível automáticas na Nova Zelândia não conseguiam processar pagamentos com cartão, forçando alternativas em dinheiro ou baseadas em app.
  • Alguns sistemas de cartão de crédito e faturação agendaram mal vencimentos ou notificações ao encontrar 29 de fevereiro.
• Sistemas do mundo físico apresentaram falhas:
  • Cartões de acesso de hotéis pararam de funcionar, exigindo reinicializações especiais de hardware; um problema semelhante foi citado de 2020.
  • Iluminação pública em Paris e em pelo menos um campus permaneceu apagada à noite, provavelmente devido a controlo baseado na data.
  • Câmeras de controlo de acesso e alguns sistemas de monitorização solar/energética bloquearam a entrada ou pararam de registar dados.
• Serviços de consumo e jogos:
  • Vários títulos da EA e jogos específicos (por exemplo, títulos de corrida e de ritmo) crashavam ou impediam o acesso dos jogadores até os relógios do sistema serem movidos para 1 de março.
  • Aplicações de companhias aéreas e de transporte imprimiram datas erradas ou rotularam mal horários, às vezes com banners de aviso como solução temporária.
  • A faturação da Cloudflare produziu faturas datadas de “1970-01-01” juntamente com um incidente de faturação mais amplo.

Armadilhas de programação com anos bissextos

• Muitos bugs vieram de lógica ingénua de “adicionar/subtrair um ano”:
  • Código que usava replace(year=year±1) ou assumia 365 dias lançava erros ou produzia datas erradas (por exemplo, 1894‑02‑29 no DB2).
  • Cálculos de ano móvel e YTD falhavam porque não existe 29 de fevereiro no ano de comparação.
  • Testes unitários que dependem de “hoje” ou assumem comprimentos fixos de ano quebravam no CI.
• Python, Java e outros foram discutidos:
  • timedelta/Duration padrão suportam apenas dias/segundos; “anos” são ambíguos.
  • Bibliotecas como relativedelta do dateutil, Arrow, Carbon, date-fns e AddYears do .NET foram citadas como opções mais seguras, mas os casos-limite ainda exigem decisões explícitas.
• Debate sobre a definição:
  • “Subtrair um ano” pode significar 365/365.25 dias, a mesma data de calendário, ou a mesma data “semântica” (por exemplo, a última segunda-feira de janeiro).
  • Vários argumentam que qualquer comportamento é aceitável desde que seja consistente e não quebre; outros enfatizam que regras legais e de negócio normalmente esperam “12 meses de calendário”.

Esquisitices de experiência do utilizador e aniversários

• Muitos relógios, apps e formulários simplesmente ignoravam 29 de fevereiro, mostravam 1 de março ou proibiam o dia 29 como uma data válida de fevereiro; alguns dispositivos codificam intencionalmente fevereiro como tendo apenas 28 dias.
• Aniversários em dia bissexto expuseram casos-limite:
  • Sistemas os mapeiam de várias formas para 28 de fevereiro ou 1 de março para verificações de idade, licenças e limites legais, às vezes bloqueando ações incorretamente.
  • Pessoas relatam formulários sem 29 de fevereiro, ou frontends que o aceitam mas o guardam como 28 de fevereiro.

LLMs e lições gerais

• Vários relatos de que o ChatGPT e outros LLMs:
  • Inicialmente afirmaram que 2024 não é um ano bissexto ou rejeitaram 2024‑02‑29 como inválido, depois autocorrigiram-se a meio da explicação.
  • Têm dificuldade com tarefas relacionadas com tokenização (por exemplo, contar letras numa palavra).
• Alguns veem isso como prova de que LLMs não devem alimentar lógica crítica; outros argumentam que eles são adequados para fluxos de trabalho não críticos, com humano no circuito, desde que isolados.
• O consenso geral: lidar com tempo é enganadoramente difícil; não crie a sua própria lógica de datas nem ignore 29 de fevereiro/regras de séculos, e faça testes cobrirem explicitamente estes casos-limite.