Whenever – techniques de gestion des dates et heures sûres en types et vis-à-vis du DST pour Python

• Whenever est une bibliothèque qui améliore datetime de Python en apportant une sécurité vis-à-vis du DST et une sécurité de typage
• Elle peut être utilisée avec Rust et en Python pur, avec d’excellentes performances
• Elle surpasse la bibliothèque standard Python ainsi que Arrow et Pendulum en gestion du DST et en sécurité de typage
• Elle prend en charge la précision à la nanoseconde et les dernières améliorations du GIL, tout en améliorant les performances via une extension Rust
• Elle est proposée sous licence MIT et continue d’être améliorée grâce aux retours

---

Présentation de Whenever

• Whenever est une bibliothèque développée pour dépasser les limites du module datetime de Python
• Elle fournit une sécurité vis-à-vis du DST et une sécurité de typage, ce qui améliore la fiabilité du code
• Elle est implémentée en Rust et en Python pur, avec d’excellentes performances

Limites de la bibliothèque standard

• Le datetime de Python ne prend pas toujours DST en compte
• Le système de types ne permet pas de distinguer les datetime naïfs et aware

Comparaison avec d’autres bibliothèques

• Arrow propose une API conviviale, mais ne résout pas les problèmes fondamentaux
• Pendulum a corrigé certains problèmes liés au DST, mais avec une baisse de performances et un manque de maintenance

Avantages de Whenever

• Fournit une arithmétique sûre vis-à-vis du DST et une API sûre en matière de types
• Offre d’excellentes performances, encore améliorées via une extension Rust
• Prend en charge la précision à la nanoseconde et les dernières améliorations du GIL

Démarrage rapide

• Fournit des types explicites comme Instant, ZonedDateTime, LocalDateTime, etc.
• Permet une arithmétique sûre vis-à-vis du DST et des conversions explicites
• Prend en charge le formatage et le parsing des formats ISO8601, RFC3339 et RFC2822

Feuille de route

• Version 0.x : atteindre la parité fonctionnelle et améliorer l’API
• Version 1.0 : garantir la stabilité de l’API et la compatibilité ascendante

Limites

• Prise en charge du calendrier grégorien de l’an 1 à 9999
• Prise en charge des offsets de fuseau horaire conformes à IANA TZ DB
• Les secondes intercalaires ne sont pas prises en charge

Politique de versionnage et de compatibilité

• Whenever suit le versionnage sémantique
• L’API peut encore évoluer avant la version 1.0

Licence

• Fourni sous licence MIT, avec des dépendances Rust utilisant des licences permissives similaires

Remerciements

• Inspiré par les projets Temporal, Noda Time et Joda Time
• Basé sur les graphiques de comparaison de benchmarks du projet Ruff

[GN⁺]

Commentaire Hacker News

• Si vous n’avez pas lu le billet de blog qui explique pourquoi cette bibliothèque existe, je le recommande. Son titre est « Ten Python datetime pitfalls, and what libraries are (not) doing about it) »
• Cette bibliothèque corrige le problème de violation de Liskov de la bibliothèque standard. Dans la bibliothèque standard, on peut comparer des dates, mais si on compare un datetime avec une date, cela provoque une erreur. J’ai récemment eu des difficultés au travail à cause de ce problème
• J’ai utilisé Arrow, Delorean, Pendulum et le datetime de la bibliothèque standard, mais j’ai fini par choisir Whenever. En pratique, il semble mieux adapté à la gestion des datetime et paraît maintenu plus activement. J’ai toujours eu l’impression que les autres bibliothèques laissaient passer des cas limites. Pendulum semble plus profondément ancré dans l’API
• Suis-je le seul à utiliser la bibliothèque standard, à lire attentivement la documentation et le changelog, puis à implémenter les fonctionnalités nécessaires ? J’ai appris à mes dépens que les dépendances peuvent ruiner un projet. Cela ne veut pas dire que cette bibliothèque n’est pas excellente. Elle a bien sûr ses cas d’usage
• Disponible en Rust ou en Python pur. La complexité d’utiliser ou de devoir compiler des paquets binaires ne vaut pas le gain de performance. La version en Python pur doit être construite depuis les sources et nécessite de passer des flags spéciaux, donc on ne peut pas la spécifier dans requirements.txt
• Si les performances ne sont pas la priorité absolue, la version en Python pur reste utilisable. J’aurais aussi aimé voir des benchmarks de l’implémentation en Python pur. Et si elle était moins performante qu’Arrow ?
• C’est amusant que Pandas n’ajoute pas la comparaison de datetime. C’est probablement utilisé pour traiter plus de dates que les autres bibliothèques
• Quelqu’un sait-il quand les problèmes de performance deviennent vraiment importants ? Je considère les datetime comme des objets éphémères. On ne voudrait pas avoir des milliers d’objets datetime dans une base de code. Dans presque tous les cas, UTC suffit. Lorsqu’il faut filtrer/mettre en buckets/agréger par plage, on utilise un datetime avec tz pour définir les critères de filtrage, de bucketisation ou d’agrégation, puis on convertit cela en UTC pour continuer à faire des comparaisons d’entiers. La plupart des cas que Whenever traite concernent probablement des datetime qui sont des objets de longue durée. Je n’en ressens absolument pas le besoin. Je l’utilise pour accepter une entrée tz depuis le client, puis je la convertis immédiatement en UTC à l’arrivée. Si on a vraiment besoin du fuseau horaire, on le stocke séparément. Cela arrive rarement (par exemple, dans un calendrier, il faut stocker le fuseau horaire, mais probablement pas à côté de chaque UTC ; il faudrait plutôt le stocker au niveau de l’utilisateur. Un autre exemple est la planification du personnel, où 8am-4pm ou 8pm-4am peuvent avoir une signification différente selon le lieu. À ce stade, ce n’est plus vraiment un datetime, mais une heure dans un fuseau horaire)
• J’utilise Arrow quand je veux plus que le strict minimum. Cette bibliothèque est assez intéressante. Pas tant pour une meilleure couverture des cas limites, mais parce qu’elle propose à la fois un mode Rustified et un mode Python pur. Avec Whenever, pas besoin de se soucier d’autre chose, ni de revenir à datetime quand on veut une meilleure gestion des dates et heures dans un projet. Elle peut aussi être utilisée dans des environnements sans toolchain Rust, ou dans des environnements problématiques. Kudos
• J’ai l’impression qu’il faudrait créer une suite de tests à l’échelle de l’industrie / des langages. Quelque chose qui puisse tester de nombreuses bibliothèques de date/heure/calendrier. Un peu comme un test acide pour les navigateurs, mais centré uniquement sur les fonctionnalités de base. J’aime bien cette nouvelle bibliothèque (merci), mais son nom semble suggérer le contraire de ce qu’elle est en réalité. « Whenever » donne l’impression qu’on s’en moque, alors qu’en pratique on ne l’utiliserait que lorsqu’on s’en soucie. Et puis Shakira, haha. Hmm, pedantic est déjà pris. Timely, precise, punctual, meticulous, ahorita, pronto, etc. J’aime bien les noms liés au temps. Enfin, aucun de ces liens ne mentionne l’immuabilité, alors que cela devrait être mis tout en haut