Whenever – Typ- und DST-sichere Datums- und Zeitverarbeitung für Python

• Whenever ist eine Bibliothek, die Pythons datetime verbessert und DST-Sicherheit sowie Typsicherheit bietet
• Sie kann mit Rust und in reinem Python verwendet werden und liefert eine starke Performance
• Gegenüber der Python-Standardbibliothek sowie Arrow und Pendulum ist sie bei DST-Verarbeitung und Typsicherheit überlegen
• Sie unterstützt Nanosekunden-Präzision und aktuelle GIL-Verbesserungen und steigert die Leistung durch eine Rust-Erweiterung
• Sie wird unter der MIT-Lizenz bereitgestellt und anhand von Feedback kontinuierlich verbessert

---

Einführung in Whenever

• Whenever ist eine Bibliothek, die entwickelt wurde, um die Grenzen von Pythons datetime-Modul zu überwinden
• Sie bietet DST-Sicherheit und Typsicherheit und erhöht damit die Korrektheit von Code
• Sie ist in Rust und reinem Python implementiert und bietet starke Performance

Grenzen der Standardbibliothek

• Pythons datetime berücksichtigt DST nicht immer
• Im Typsystem lassen sich naive und aware Datetime-Werte nicht unterscheiden

Vergleich mit anderen Bibliotheken

• Arrow bietet eine benutzerfreundliche API, löst aber die Kernprobleme nicht
• Pendulum behebt einige DST-Probleme, hat jedoch Performance-Nachteile und wird nur unzureichend gepflegt

Vorteile von Whenever

• Bietet DST-sichere arithmetische Operationen und eine typsichere API
• Liefert starke Performance, die durch die Rust-Erweiterung weiter verbessert wird
• Unterstützt Nanosekunden-Präzision und aktuelle GIL-Verbesserungen

Schnellstart

• Bietet explizite Typen wie Instant, ZonedDateTime, LocalDateTime usw.
• Ermöglicht DST-sichere arithmetische Operationen und explizite Konvertierungen
• Unterstützt Formatierung und Parsing der Formate ISO8601, RFC3339 und RFC2822

Roadmap

• Version 0.x: Erreichen von Funktionsgleichheit und Verbesserung der API
• Version 1.0: Sicherstellung von API-Stabilität und Abwärtskompatibilität

Einschränkungen

• Unterstützt den gregorianischen Kalender vom Jahr 1 bis 9999
• Unterstützt Zeitzonen-Offsets, die mit der IANA TZ DB übereinstimmen
• Schaltsekunden werden nicht unterstützt

Versionsverwaltung und Kompatibilitätsrichtlinie

• Whenever folgt dem Semantic Versioning
• Vor Version 1.0 sind API-Änderungen möglich

Lizenz

• Wird unter der MIT-Lizenz bereitgestellt; Rust-Abhängigkeiten verwenden ähnliche permissive Lizenzen

Danksagung

• Inspiriert von den Projekten Temporal, Noda Time und Joda Time
• Basierend auf den Benchmark-Vergleichsgrafiken des Ruff-Projekts

[GN⁺]

Hacker-News-Kommentare

• Falls man den Blogbeitrag, der erklärt, warum diese Bibliothek existiert, noch nicht gelesen hat, ist er sehr zu empfehlen. Der Titel lautet "Ten Python datetime pitfalls, and what libraries are (not) doing about it"
• Diese Bibliothek behebt das Liskov-Verletzungsproblem der Standardbibliothek. In der Standardbibliothek kann man Datumswerte vergleichen, aber wenn man datetime und date miteinander vergleicht, tritt ein Fehler auf. Ich hatte kürzlich bei der Arbeit wegen dieses Problems Schwierigkeiten
• Ich habe Arrow, Delorean, Pendulum und das datetime der Standardbibliothek verwendet, mich am Ende aber für Whenever entschieden. Es scheint tatsächlich besser für den Umgang mit datetime geeignet zu sein und aktiver gepflegt zu werden. Bei den anderen Bibliotheken hatte ich immer das Gefühl, dass sie Edge Cases übersehen. Pendulum scheint tiefer in die API eingebettet zu sein
• Bin ich der Einzige, der die Standardbibliothek verwendet, die Dokumentation und das Changelog sorgfältig liest und die benötigten Funktionen selbst implementiert? Ich habe auf die harte Tour gelernt, dass Abhängigkeiten ein Projekt ruinieren können. Das heißt nicht, dass diese Bibliothek nicht großartig ist. Natürlich gibt es Anwendungsfälle dafür
• Wird in Rust oder als reines Python angeboten. Die Komplexität, Binärpakete zu verwenden oder Builds durchführen zu müssen, ist den Performance-Vorteil nicht wert. Die reine-Python-Version muss aus dem Quellcode gebaut werden und erfordert spezielle Flags, daher kann man sie nicht in der requirements.txt angeben
• Wenn Performance nicht oberste Priorität hat, kann man auch die reine-Python-Version verwenden. Ich hätte gerne auch Benchmarks der reinen-Python-Implementierung gesehen. Was, wenn sie langsamer als Arrow ist?
• Es ist interessant, dass Pandas keinen datetime-Vergleich hinzufügt. Vermutlich wird es zum Verarbeiten von mehr Datumswerten verwendet als die anderen Bibliotheken
• Weiß jemand, wann Performance-Probleme wirklich wichtig werden? Ich verstehe datetime als kurzlebige Objekte. Man will vermutlich keine Tausenden von datetime-Objekten in einer Codebasis haben. In fast allen Fällen reicht UTC aus. Wenn man nach Bereichen filtern, bucketen oder aggregieren muss, verwendet man datetime mit tz, um die Kriterien für Filtern/Bucketing/Aggregation festzulegen, wandelt das dann in UTC um und macht weiterhin reine int-Vergleiche. Die meisten Fälle, die Whenever behandelt, dürften solche sein, in denen datetime langlebige Objekte sind. Ich hatte nie das Bedürfnis danach. Ich verwende es, um tz-Eingaben vom Client zu akzeptieren, und wandle sie sofort bei Eingang in UTC um. Wenn man tz wirklich braucht, speichert man es separat. Das kommt selten vor (z. B. sollte man in Kalendern tz speichern, aber vermutlich nicht neben jedem UTC-Wert, sondern auf Benutzerebene. Ein anderes Beispiel ist die Personaleinsatzplanung, bei der 8am-4pm oder 8pm-4am je nach Ort etwas anderes bedeuten kann. Das ist dann kein datetime mehr, sondern eine Uhrzeit in einer Zeitzone)
• Ich verwende Arrow, wenn ich mehr als nur Grundfunktionen brauche. Diese Bibliothek ist ziemlich interessant. Nicht wegen einer größeren Abdeckung von Edge Cases, sondern weil sowohl ein Rustified-Modus als auch ein reiner Python-Modus angeboten werden. Mit Whenever muss man sich um nichts anderes kümmern und nicht wieder zu datetime zurückkehren, wenn man im Projekt eine bessere datetime-Behandlung möchte. Es ist auch in Umgebungen ohne Rust-Toolchain oder mit problematischer Rust-Toolchain nutzbar. Kudos
• Es scheint, als müsste man eine branchen- bzw. sprachübergreifende Testsuite erstellen, mit der sich viele Datums-/Zeit-/Kalenderbibliotheken testen lassen. So etwas wie Browser-Acid-Tests, aber nur auf Grundfunktionen fokussiert. Ich mag diese neue Bibliothek (danke dafür), aber der Name deutet das Gegenteil von dem an, was sie tatsächlich ist. "Whenever" klingt so, als wäre es einem egal, aber tatsächlich würde man sie nur verwenden, wenn es einem eben nicht egal ist. Und dann noch Shakira, haha. Hmm, pedantic ist schon vergeben. Timely, precise, punctual, meticulous, ahorita, pronto usw. Ich mag zeitbezogene Namen. Und zuletzt: Keiner dieser Links erwähnt Unveränderlichkeit, dabei sollte das ganz oben genannt werden