Whenever: Typed and DST-safe datetimes for Python

Python datetime pain points

• Several comments recount long-standing frustration with datetime, especially:
  • Naive vs aware confusion and DST-related bugs.
  • The inheritance design where datetime is a subclass of date, yet cross-type comparisons (e.g., datetime < date) fail, which some see as a Liskov substitution violation.
  • Deprecated or misleading APIs like utcnow, described as “broken footguns” that must be avoided via linting or discipline.

Whenever’s design and alternatives

• Some users report moving from Arrow/Delorean/Pendulum to Whenever, saying it better matches real-world use and feels more robust on edge cases.
• Others stick to stdlib + custom helpers, arguing they’d rather understand and wrap the existing quirks than add another dependency.
• A few suggest this kind of library would be a good candidate for eventual inclusion or inspiration for a better Python standard API, similar to how Java’s modern time API evolved from Joda-Time.

Rust vs pure-Python implementation

• There’s significant debate over the Rust-backed core:
  • Critics dislike needing a non-pure-Python dependency or environment variables to select the pure-Python build, which complicates requirements.txt and some environments.
  • Suggested alternatives include separate packages (e.g., whenever vs whenever-rust) or extras, but the author argues this creates confusion and that most users expect the fast version by default.
• Benchmarks in the FAQ: Rust version ≈ 10x faster than the pure-Python version; pure Python still roughly competitive with Arrow/Pendulum but slower than stdlib.

Dependencies vs standard library

• One camp: avoid third‑party datetime libs; stdlib is heavily tested, and extra deps create long-term maintenance, security, and upgrade burdens.
• Opposing camp: datetime is sufficiently tricky (DST, calendar rules, political time changes) that relying on experts and a well-tested library is safer than rolling ad‑hoc helpers in every codebase.
• There is extended meta-discussion about dependency hell, update practices, hidden “homegrown” tech debt, and how often to upgrade libraries.

DST, timezones, and calendar semantics

• Some hope DST is abolished, but others note that:
  • Politics and economics make uniform changes unlikely; neighboring countries may end up with misaligned time zones.
  • Even if DST went away, code must still correctly handle historical timestamps.
• Several comments emphasize:
  • Use location-based tz IDs (IANA tz database) instead of vague labels like “Pacific Standard Time.”
  • Store events differently depending on semantics: UTC for “when it happened”; local time + zone for future scheduling (e.g., recurring lunches that should stay at 12:00 local despite DST shifts).
• There’s a nuanced debate over whether long-lived timezone-aware datetimes are necessary or whether systems should mostly convert to UTC early and treat many problems as “time + recurrence rule” rather than rich datetime objects.

Parsing timestamps and ISO 8601

• Multiple participants say parsing messy real-world timestamp strings is a larger pain point than DST itself.
• Pandas is praised for pragmatic, flexible parsing of many “sensible” ISO-like formats and variants; some wish Whenever would prioritize similarly broad, forgiving parsing modes.
• The library author acknowledges the complexity of full ISO support and is expanding coverage, taking cues from JavaScript’s Temporal spec. There is discussion about:
  • How far to go with flexible parsing vs strict specs.
  • Tradeoffs between permissive parsing and clear error reporting.
  • Possibly offering an explicit “best-effort / flexible” parsing mode built on a rigorous core.

Standardization and testing

• Some see Whenever as echoing Java’s JSR‑310 design and view Python’s lack of a modern, unified datetime API as a long-standing weakness.
• There’s a proposal for an “Acid test”-style cross-language datetime test suite, though others note that live timezone data changes constantly, complicating such tests.
• Overall sentiment: time is deceptively hard, and a coherent, well-typed, DST-safe library is welcome, but opinions diverge sharply on performance, packaging, and whether to depend on it versus mastering the stdlib.