New submission from Paul G:
According to PEP495
(https://www.python.org/dev/peps/pep-0495/#aware-datetime-equality-comparison)
datetimes are considered not equal if they are an ambiguous time and have
different zones. However, currently "interzone comparison" is defined /
implemented as the zones being the same object rather than the zones comparing
equal.
One issue with this is that it actually breaks backwards compatibility of the
language, because there doesn't seem to be a way to provide a
(backwards-compatible) class that implements folding behavior and has
equivalent dates compare equal. An example using python-dateutil:
```
from datetime import datetime
from dateutil import tz
NYC = tz.gettz('America/New_York')
ET = tz.gettz('US/Eastern')
dt = datetime(2011, 11, 6, 5, 30, tzinfo=tz.tzutc()) # This is 2011-11-06 01:30
EDT-4
dt_edt = dt.astimezone(ET)
dt_nyc = dt.astimezone(NYC)
print(dt_nyc == dt_edt)
```
In Python 3.5 that will return True, in Python 3.6 it will return False, even
though 'US/Eastern' and 'America/New_York' are the same zone. In this case, I
might be able to enforce that these time zones are singletons so that `is`
always returns True (though this may have other negative consequences for
utility), but even that solution would fall apart for things like `tzrange` and
`tzstr`, where you can know that the `dt.utcoffset()`s are going to be
identical for ALL values of `dt`, but you can't force the objects to be
identical.
I would suggest that it be changed to use `__eq__` to determine whether two
`tzinfo` objects are the same zone, as this will allow tzinfo providers to
create `tzinfo` objects with a consistent behavior between versions in this
edge case.
----------
components: Library (Lib)
messages: 280003
nosy: belopolsky, p-ganssle
priority: normal
severity: normal
status: open
title: Ambiguous datetime comparisons should use == rather than 'is' for tzinfo
comparison
type: behavior
versions: Python 3.6, Python 3.7
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28601>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
