Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ambiguous datetime comparisons should use == rather than 'is' for tzinfo comparison #72787

Open
pganssle opened this issue Nov 3, 2016 · 2 comments
Assignees
Labels
3.7 (EOL) end of life stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@pganssle
Copy link
Member

pganssle commented Nov 3, 2016

BPO 28601
Nosy @tim-one, @abalkin, @pganssle

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = 'https://github.com/abalkin'
closed_at = None
created_at = <Date 2016-11-03.18:37:19.485>
labels = ['3.7', 'type-bug', 'library']
title = "Ambiguous datetime comparisons should use == rather than 'is' for tzinfo comparison"
updated_at = <Date 2016-11-03.18:46:38.618>
user = 'https://github.com/pganssle'

bugs.python.org fields:

activity = <Date 2016-11-03.18:46:38.618>
actor = 'belopolsky'
assignee = 'belopolsky'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2016-11-03.18:37:19.485>
creator = 'p-ganssle'
dependencies = []
files = []
hgrepos = []
issue_num = 28601
keywords = []
message_count = 2.0
messages = ['280003', '280005']
nosy_count = 3.0
nosy_names = ['tim.peters', 'belopolsky', 'p-ganssle']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue28601'
versions = ['Python 3.6', 'Python 3.7']

@pganssle
Copy link
Member Author

pganssle commented Nov 3, 2016

According to PEP-495 (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.

@pganssle pganssle added 3.7 (EOL) end of life stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Nov 3, 2016
@abalkin
Copy link
Member

abalkin commented Nov 3, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.7 (EOL) end of life stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
Projects
Development

No branches or pull requests

2 participants