On Tue, Sep 1, 2015 at 12:36 PM, Carl Meyer <[email protected]> wrote:
> 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). Here is an idea that I think may work: let's consider fold=1 instances as if they have a different tzinfo instance from the other side in both datetime subtractions and comparisons. This will be consistent with the current stdlib and pytz work-arounds of representing "second" times using fictitious fixed-offset timezones.
_______________________________________________ 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/
