Whenever – técnica de manejo de fecha y hora segura para tipos y DST en Python

• Whenever es una biblioteca que mejora datetime de Python al ofrecer seguridad frente a DST y seguridad de tipos
• Puede usarse con Rust y con Python puro, y ofrece alto rendimiento
• Supera a la biblioteca estándar de Python, así como a Arrow y Pendulum, en manejo de DST y seguridad de tipos
• Soporta precisión de nanosegundos y las mejoras más recientes del GIL, y mejora el rendimiento mediante una extensión en Rust
• Se ofrece bajo licencia MIT y sigue mejorando continuamente a partir del feedback

---

Introducción a Whenever

• Whenever es una biblioteca desarrollada para superar las limitaciones del módulo datetime de Python
• Ofrece seguridad frente a DST y seguridad de tipos, lo que mejora la precisión del código
• Está implementada en Rust y Python puro, con un rendimiento sobresaliente

Limitaciones de la biblioteca estándar

• datetime de Python no siempre toma en cuenta el DST
• El sistema de tipos no puede distinguir entre datetime naive y aware

Comparación con otras bibliotecas

• Arrow ofrece una API fácil de usar, pero no resuelve los problemas fundamentales
• Pendulum corrigió algunos problemas de DST, pero tiene menor rendimiento y poco mantenimiento

Ventajas de Whenever

• Ofrece operaciones aritméticas seguras frente a DST y una API segura en tipos
• Tiene alto rendimiento, que mejora aún más con la extensión en Rust
• Soporta precisión de nanosegundos y las mejoras más recientes del GIL

Inicio rápido

• Proporciona tipos explícitos como Instant, ZonedDateTime y LocalDateTime
• Permite operaciones aritméticas seguras frente a DST y conversiones explícitas
• Soporta formateo y parsing en formatos ISO8601, RFC3339 y RFC2822

Hoja de ruta

• Versión 0.x: alcanzar paridad funcional y mejorar la API
• Versión 1.0: asegurar estabilidad de la API y compatibilidad hacia atrás

Limitaciones

• Soporta el calendario gregoriano desde el año 1 hasta el 9999
• Soporta offsets de zona horaria alineados con la IANA TZ DB
• No soporta segundos intercalares

Política de versionado y compatibilidad

• Whenever sigue el versionado semántico
• Antes de la versión 1.0, puede haber cambios en la API

Licencia

• Se ofrece bajo licencia MIT, y las dependencias de Rust usan licencias permisivas similares

Agradecimientos

• Está inspirada en los proyectos Temporal, Noda Time y Joda Time
• Se basa en el gráfico comparativo de benchmarks del proyecto Ruff

[GN⁺]

Comentarios en Hacker News

• Si no has leído la entrada de blog que explica por qué existe esta biblioteca, la recomiendo. El título es "Ten Python datetime pitfalls, and what libraries are (not) doing about it"
• Esta biblioteca resuelve el problema de violación de Liskov en la biblioteca estándar. En la biblioteca estándar se pueden comparar fechas, pero si comparas datetime con fecha se produce un error. Hace poco tuve problemas en el trabajo por este tema
• He usado Arrow, Delorean, Pendulum y datetime de la biblioteca estándar, pero al final elegí Whenever. En verdad parece más adecuada para manejar datetime y da la impresión de tener un mantenimiento más activo. Siempre sentí que las otras bibliotecas dejaban fuera casos límite. Pendulum parece estar más profundamente integrado en su API
• ¿Soy el único que usa la biblioteca estándar, lee con cuidado la documentación y el changelog, e implementa lo que necesita? Aprendí por las malas que las dependencias arruinan los proyectos. No significa que esta biblioteca no sea excelente. Claro que tiene casos de uso
• Se ofrece en Rust o en Python puro. La complejidad de usar paquetes binarios o tener que compilar no vale la pena frente a la ventaja de rendimiento. La versión en Python puro tiene que compilarse desde el código fuente y pasar flags especiales, así que no se puede especificar en requirements.txt
• Si el rendimiento no es la prioridad máxima, también se puede usar la versión en Python puro. También me habría gustado ver benchmarks de la implementación en Python puro. ¿Y si rinde peor que Arrow?
• Es curioso que en Pandas no agreguen comparación de datetime. Probablemente se use para manejar más fechas que las demás bibliotecas
• ¿Alguien sabe cuándo importan realmente los problemas de rendimiento? Entiendo datetime como un objeto de vida corta. No querrías miles de objetos datetime en una base de código. En casi todos los casos, UTC es suficiente. Cuando tienes que filtrar/agrupar en buckets/agregar por rango, usas datetime con tz para establecer el criterio de filtrado/bucket/agregación, lo conviertes a UTC y sigues haciendo comparaciones de int. La mayoría de los casos que maneja Whenever serían cuando datetime es un objeto de larga vida. No siento esa necesidad en absoluto. Lo uso para aceptar entradas de tz del cliente y lo convierto a UTC en cuanto llega. Si de verdad necesito tz, lo guardo por separado. Eso pasa rara vez (por ejemplo, en calendarios hay que guardar tz, pero probablemente no haga falta guardarlo junto a cada UTC, sino a nivel de usuario. Otro ejemplo es la planificación de personal, donde 8am-4pm o 8pm-4am pueden significar algo distinto según la ubicación. Eso ya no es un datetime, sino la hora de una zona horaria)
• Uso Arrow cuando quiero algo más que lo básico. Esta biblioteca es bastante interesante. No por una mayor cobertura de casos límite, sino porque ofrece tanto modo Rustified como modo Python puro. Con Whenever no hace falta preocuparse por otra cosa y no hay necesidad de volver a datetime cuando quieres un mejor manejo de fechas y horas en un proyecto. También se puede usar en entornos sin toolchain de Rust o donde este dé problemas. Kudos
• Parece que deberíamos crear una suite de pruebas para toda la industria/lenguajes. Algo que pueda probar muchas bibliotecas de fecha/hora/calendario. Similar a una prueba ácida para navegadores, pero enfocada solo en la funcionalidad básica. Me gusta esta nueva biblioteca (gracias), pero su nombre sugiere lo contrario de lo que realmente es. "Whenever" suena a que no te importa, pero en realidad solo la usarías cuando sí te importa. Y también Shakira, jaja. Hmm, pedantic ya está en uso. Timely, precise, punctual, meticulous, ahorita, pronto, etc. Me gustan los nombres relacionados con el tiempo. Por último, ninguno de estos enlaces menciona la inmutabilidad, pero debería estar mencionada hasta arriba