[Guido] >> But it breaks compatibility: it breaks the rule that for fold=0 nothing >> changes.
[Alex] > It preserves a "weak form" of compatibility: nothing changes in the behavior > of aware datetime objects unless they use a post-PEP tzinfo. In that specific way, it's "more backward compatible" than the "special-case-the-snot-out-of-fold=1 in interzone __eq__ and __ne__", but it's subtle: Some datetime class constructors, like .now() and today(), can set fold=1 even if no post-495 tzinfos exist, based on Python's own idea of what the system zone rules are. If one of those happens to be generated during a repeated time in the system zone, and a pre-495 tzinfo is attached, then special-casing fold=1 makes it "not equal" to anything in any other zone despite that a pre-495 tzinfo is in use. That's certainly breaking _some_ form of backward compatibility, however obscure. But under Alex's latest idea, that wouldn't break: the pre-495 tzinfo's .utcoffset() would return the same thing regardless of `fold`, so the new __eq__ wouldn't see any problem with it. The latest idea is based on determining whether a time is _really_ "a problem case", and to a pre-495 tzinfo nothing is. Just staring at `fold` without consulting the tzinfo is guessing at whether it _might_ be a real problem for the tzinfo in use, and in fact always guesses wrong when fold=1 and a pre-495 tzinfo is in use. > Note that Solution 2 also breaks a "strong form" of compatibility (nothing > changes unless fold=1) because pre-PEP tzinfos are supposed to interpret > times in the fold as STD (fold=1). Note that in my experience very few > tzinfo developers understand this requirement and with a run-of-the-mill > tzinfo you have a 50/50 chance that it will interpret ambiguous times as > fold=0 or fold=1. Well, if they copied the Python doc examples, they got this "right". If they're using dateutil's wrappings, they also got this right. And it's a non-issue in pytz, because that only ever uses fixed-offset classes. The three users who remain will just have to eat their own hasty cooking ;-) > ... > Once you decide to use a post-PEP tzinfo, you have no choice but to test > your software on the edge cases if you care about them. (And you probably > do if you bother to switch to a post-PEP tzinfo.) If you don't care about > edge cases, you can continue using pre-PEP tzinfos or switch and accept a > more consistent but different edge case behavior. Yup! The new idea is cleaner and clearer. But runs slower ;-) _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
