Why Pendulum had to write the most cursed "+" operator in all of Python

Pendulum’s overloaded + operator inspects the Python call stack to decide whether to perform DST-aware “elapsed time” arithmetic or mimic the standard library’s wall-clock behavior. It does this by calling traceback.extract_stack() and checking the caller’s name (looking for "astimezone"), so renaming a function can change the result. That hack was motivated by two conflicting promises: provide DST-correct arithmetic while remaining a drop-in subclass of datetime. Because the standard library’s astimezone conversion calls ZoneInfo.fromutc() which itself uses + expecting wall-clock semantics, Pendulum tried to guess which + was intended. The guess is fragile (misses other callers such as dateutil, behaves differently on PyPy), expensive (stack inspection makes + roughly 600× slower than the stdlib in tests), and introduces other guesses elsewhere (defaulting to UTC, using today’s date for time-only parses, flipped fold behavior), producing silently wrong or environment-dependent results.

A less cursed workaround - convert a Pendulum instance to a plain datetime before calling the stdlib astimezone and wrap the result - was proposed and merged, which removes the need for the call-stack probe and cuts the penalty (to about 120× slower versus stdlib, leaving pure-Python arithmetic cost). But the deeper incompatibility remains: any code that treats a Pendulum DateTime as a stdlib datetime and does arithmetic will observe Pendulum semantics. A complete fix would require not subclassing datetime; the author’s alternative library avoids subclassing so values aren’t guessed silently. Users should be careful converting to third-party time zones, using + in hot loops, parsing incomplete inputs, or passing Pendulum values where a datetime is expected.