Ask HN: ¿Encontraste hoy algún bug de año bisiesto?

Discusión en Hacker News ↗

El día bisiesto de 2024 expuso una sorprendente cantidad de fallos de software y hardware, desde sistemas de pago rotos, cerraduras de control de acceso, juegos y relojes hasta pruebas unitarias, sistemas de facturación e incluso modelos de lenguaje grandes que rechazaban el 29 de febrero como inválido. Los participantes atribuyen muchos de estos errores a aritmética de fechas ingenua (como “restar un año”), a un manejo personalizado del tiempo y a casos límite como aniversarios móviles, certificados y ventanas de retención que no se probaron a través de años bisiestos. Los incidentes refuerzan el consejo de siempre: depender de bibliotecas maduras de fecha/hora, diseñar reglas de negocio más claras en torno al tiempo y probar explícitamente casos raros del calendario en lugar de asumir que “simplemente funcionarán”.

Cortes reales del mundo y problemas operativos

  • Fallaron múltiples sistemas de pago:
    • Una gran cadena de supermercados sueca y unos surtidores de combustible de autoservicio en Nueva Zelanda no pudieron procesar pagos con tarjeta, obligando a usar efectivo o soluciones alternativas basadas en apps.
    • Algunos sistemas de tarjetas de crédito y facturación reprogramaron mal vencimientos o notificaciones al encontrarse con el 29 de febrero.
  • Sistemas del mundo físico tuvieron fallos:
    • Las tarjetas llave de hoteles dejaron de funcionar y requirieron reinicios especiales de hardware; se citó un problema similar de 2020.
    • Las luces de la calle en París y al menos un campus se quedaron apagadas por la noche, probablemente debido a un control basado en la fecha.
    • Cámaras de control de acceso y algunos sistemas de monitoreo solar/energético bloquearon la entrada o dejaron de registrar datos.
  • Servicios de consumo y juegos:
    • Varios títulos de EA y juegos concretos (p. ej., de carreras y de ritmo) se bloquearon o impidieron jugar hasta que los relojes del sistema se movieron al 1 de marzo.
    • Las apps de aerolíneas y transporte imprimían fechas incorrectas o etiquetaban mal los horarios, a veces con avisos en banner como solución temporal.
    • La facturación de Cloudflare generó facturas fechadas como “1970-01-01” junto con un incidente de facturación más amplio.

Errores de programación con los años bisiestos

  • Muchos fallos vinieron de lógica ingenua de “sumar/restar un año”:
    • Código que usaba replace(year=year±1) o asumía 365 días lanzó errores o produjo fechas incorrectas (p. ej., 1894‑02‑29 en DB2).
    • Los cálculos de año móvil y YTD fallaron porque no existe el 29 de febrero en el año de comparación.
    • Las pruebas unitarias que dependen de “hoy” o asumen longitudes fijas de año fallaron en CI.
  • Se discutieron Python, Java y otros:
    • timedelta/Duration estándar solo admiten días/segundos; los “años” son ambiguos.
    • Se citaron bibliotecas como relativedelta de dateutil, Arrow, Carbon, date-fns y AddYears de .NET como opciones más seguras, aunque los casos límite aún requieren decisiones explícitas.
  • Debate sobre la definición:
    • “Restar un año” puede significar 365/365.25 días, la misma fecha del calendario o la misma fecha “semántica” (por ejemplo, el último lunes de enero).
    • Varios argumentan que cualquier comportamiento es aceptable mientras sea coherente y no falle; otros enfatizan que las reglas legales y de negocio suelen esperar “12 meses calendario”.

Rarezas de experiencia de usuario y cumpleaños

  • Muchos relojes, apps y formularios simplemente omitían el 29 de febrero, mostraban el 1 de marzo o no permitían el 29 como fecha válida de febrero; algunos dispositivos codifican intencionalmente febrero con 28 días.
  • Los cumpleaños del día bisiesto expusieron casos límite:
    • Los sistemas los asignan de forma variada al 28 de febrero o al 1 de marzo para comprobaciones de edad, licencias y umbrales legales, a veces bloqueando acciones de manera incorrecta.
    • La gente informa de formularios que no incluyen el 29 de febrero, o de frontends que lo aceptan pero lo guardan como 28 de febrero.

LLMs y lecciones meta

  • Varios reportes indican que ChatGPT y otros LLM:
    • Al principio afirmaron que 2024 no es un año bisiesto o rechazaron 2024-02-29 como inválido, y luego se autocorrigieron a mitad de la explicación.
    • Tienen dificultades con tareas relacionadas con la tokenización (por ejemplo, contar letras en una palabra).
  • Algunos ven esto como prueba de que los LLM no deberían encargarse de lógica crítica; otros sostienen que sirven para flujos de trabajo no críticos, con supervisión humana, si están aislados en un sandbox.
  • El consenso general: el manejo del tiempo es engañosamente difícil; no escribas tu propia lógica de fechas ni ignores el 29 de febrero o las reglas de siglo, y haz que las pruebas cubran explícitamente estos casos límite.