On 09/02/2015 10:07 PM, Tim Peters wrote: > [Carl Meyer] >> But the point is that changing that model (in a backwards-compatible >> way, by means of a tzinfo flag) to draw a clear line between >> timeline-mode and naive-mode, _eliminates_ almost all of that pain. All >> these puzzles about arithmetic, ordering, equality, and hashing go away >> entirely (that is, they have obvious and unsurprising answers). > > The puzzles about arithmetic, ordering, equality and hashing have > already been resolved. The problems were all due to a single cause: > ignoring fold=1 where it really matters.
But aren't we still left with arithmetic that violates basic invariants in the presence of a fold=1 datetime? [Tim] > It's unreasonable to ask people to settle for arithmetic at best 10x > slower just to get correct timezone conversions If the intended meaning of a tz-annotated datetime is "naive clock time with an associated timezone", then we don't need PEP 495; timezone conversions are already as correct as the model allows. PEP 495 just worsens the existing "naive or aware?" identity crisis of tz-annotated datetimes. > So I await the patch ;-) Fair! I'll work on one :-) > In its absence, we'll likely continue taking one useful, small step at a time. It's no longer clear to me that PEP 495 is a useful step. Carl
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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/
