Errores comunes de Python datetime, y qué están haciendo (o no) las bibliotecas al respecto

Artículo original ↗ Discusión en Hacker News ↗

Manejar fechas y horas en software resulta mucho más complejo que “solo usar UTC”, especialmente cuando entran en juego el horario de verano, las leyes cambiantes de zonas horarias y eventos futuros orientados a personas como reuniones o contratos. Los comentaristas debaten cómo debería Python `datetime` y las bibliotecas alternativas representar el tiempo: instantes UTC, horas locales de “reloj”, desfases fijos o zonas horarias IANA completas, y si las bibliotecas deberían permitir tiempos ambiguos o inexistentes. Muchos concluyen que no existe un único modelo que sirva para todos los casos, así que las bibliotecas robustas necesitan múltiples tipos explícitos y compensaciones claras en lugar de una sola abstracción mágica de marca temporal.

UTC frente a hora local y fechas futuras

  • Muchos sostienen que “guardar todo en UTC” funciona bien para eventos pasados y marcas de tiempo centradas en la máquina.
  • Otros subrayan que esto falla para horas futuras programadas por personas (reuniones, citas, contratos).
  • Punto clave: las horas futuras en reloj local suelen almacenarse como (fecha y hora local + zona horaria IANA), no preconvertidas a UTC, porque las reglas de zona horaria/DST pueden cambiar.
  • No existe una regla universal: a veces los usuarios quieren un instante fijo en UTC, y a veces una “hora local” en un lugar.

DST, zonas horarias y expectativas humanas

  • El DST y la política de zonas horarias son políticos y cambiantes; no puedes predecir las reglas futuras.
  • Los eventos recurrentes (“cada lunes a las 10:00”, “1:1 cada dos semanas a la 1 PM”) no deberían desplazarse una hora al cruzar el DST; eso requiere modelar la hora local y las zonas explícitamente.
  • Las reuniones entre continentes sufren desajustes temporales cuando las transiciones de DST ocurren en fechas distintas; los calendarios suelen elegir una zona de referencia.

Formatos de datos y épocas (ISO 8601, tiempo Unix, etc.)

  • ISO 8601 / RFC 3339 ayudan con el formato de cadenas, pero no resuelven la semántica de zona horaria/DST ni la ubicación.
  • Los formatos MM/DD/YYYY al estilo estadounidense y herramientas como Excel se consideran grandes fuentes de errores.
  • Los segundos desde la época Unix (o micro/nanosegundos enteros) son populares para la representación interna, pero el soporte pre-1970 y los segundos intercalares son complicados.

Segundos intercalares

  • Algunas bibliotecas (por ejemplo, de propósito general, incluidas las discutidas) ignoran los segundos intercalares; otras especializadas (por ejemplo, centradas en astronomía) los manejan.
  • Las opiniones difieren: algunos ven aceptable ignorar los segundos intercalares para la mayoría de las aplicaciones; otros señalan que esto rompe el cálculo preciso de duraciones/instantes y el análisis de “23:59:60”.

Diseño de bibliotecas: tipos y comportamiento

  • Fuerte apoyo a tipos distintos:
    • Instant/UTC-only,
    • ZonedDateTime (zonas IANA),
    • OffsetDateTime (desfase fijo),
    • Local/naive date-times para casos de uso de reloj local o recurrentes tipo “alarma”.
  • Combinar datos ingenuos y zonificados en un solo tipo (como en algunas bibliotecas de JS y Python) es ampliamente criticado.
  • Debate sobre representar tiempos inexistentes durante los huecos de DST:
    • Algunos prefieren prohibir o generar error en tiempos locales inválidos.
    • Otros prefieren mapeos “best-effort” deterministas y documentados, aunque sorprendan.

Concepto de “hora local”

  • Algunos argumentan que la “hora local” del sistema es un error histórico salvo para la UI y la compatibilidad con libc; mejor especificar siempre zonas horarias o ubicaciones explícitas.
  • Otros señalan que los usuarios normales y los dispositivos aún necesitan una noción de hora local de reloj para alarmas, tareas tipo cron y la semántica de “4pm en el café”.