On 09/01/2015 10:12 AM, Guido van Rossum wrote: > I'm much less concerned about < being intransitive in edge cases. I also > don't particularly care about == following from the difference being > zero. Still, unless we're constrained by backward compatibility, I would > rather not add equivalence between *any* two datetimes whose tzinfo is > not the same object -- even if we can infer that they both must refer to > the same instant.
I think the latter is certainly a backwards-compatibility requirement, since that equivalence is already very much present in the current implementation of datetime.__eq__ (well, datetime._cmp). If two datetimes have different tzinfo objects, they are converted to UTC and compared as instants. Following the same model would certainly imply that a fold=0 and fold=1 datetime that are otherwise identical should not be considered equal, because they clearly represent different instants. I guess Alex's opposition to that is the (very small) chance of backwards-incompatibility, since currently it is possible to take two non-equal UTC datetimes an hour apart at a fold, convert them to local time, and then have them compare equal (since pre PEP 495 the conversion to local time during a fold loses information). Personally I think that latter backwards-incompatibility would be a reasonable bugfix to make the existing semantics of datetime equality consistent in folds. Though I suppose it's possible someone somewhere is relying on that as a very strange way of detecting a fold? 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/
