datetime.__eq__ returns true when timezones don't match

[Woodz]

BPO	43237
Nosy	@mdickinson, @abalkin, @pganssle, @Woodz

^{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 = None
closed_at = <Date 2021-02-18.09:54:45.705>
created_at = <Date 2021-02-16.04:52:32.474>
labels = ['3.8', 'library', 'invalid']
title = "datetime.__eq__ returns true when timezones don't match"
updated_at = <Date 2021-02-18.09:54:45.704>
user = 'https://github.com/Woodz'

bugs.python.org fields:

activity = <Date 2021-02-18.09:54:45.704>
actor = 'mark.dickinson'
assignee = 'none'
closed = True
closed_date = <Date 2021-02-18.09:54:45.705>
closer = 'mark.dickinson'
components = ['Library (Lib)']
creation = <Date 2021-02-16.04:52:32.474>
creator = 'Woodz'
dependencies = []
files = []
hgrepos = []
issue_num = 43237
keywords = []
message_count = 3.0
messages = ['387087', '387100', '387207']
nosy_count = 4.0
nosy_names = ['mark.dickinson', 'belopolsky', 'p-ganssle', 'Woodz']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue43237'
versions = ['Python 3.8']

[Woodz]

from datetime import datetime, timezone, timedelta

datetime_in_sgt = datetime(2021, 2, 16, 8, 0, 0, tzinfo=timezone(timedelta(hours=8)))
datetime_in_utc = datetime(2021, 2, 16, 0, 0, 0, tzinfo=timezone.utc)

print(datetime_in_sgt == datetime_in_utc)

Expected: False
Actual: True

Although these two datetimes represent the same instant on the timeline, they are not identical because they use different timezones. This means that when unit testing timezone handling, tests will incorrectly pass despite data being returned in UTC instead of the requested timezone, so we need to write code such as this:

# Timestamp comparison
self.assertEqual(datetime_in_sgt, datetime_in_utc)
# Timezone comparison
self.assertEqual(datetime_in_sgt.tzinfo, datetime_in_utc.tzinfo)

This is confusing and non-intuitive.

For examples of how other languages handle such comparison, can refer to: https://docs.oracle.com/javase/8/docs/api/java/time/ZonedDateTime.html#equals-java.lang.Object- and
https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html#equals-java.lang.Object-

[mdickinson]

Hi Richard. Thanks for the report. Python's working as designed (and as documented and tested) here. IOW, the behaviour is deliberate - this isn't a bug.

Any change in behaviour would have to target 3.10 at the earliest (and it's already quite late in the release process for 3.10). A couple of questions: (1) what would you want the comparisons datetime_in_sgt <= datetime_in_utc and datetime_in_utc <= datetime_in_sgt to give? (2) How would you propose to change the behaviour without breaking existing code that makes use of the current behaviour?

This is confusing and non-intuitive.

That's a rather subjective judgement. I'd personally find the behaviour you suggest non-intuitive (and I find the behaviour of Java's order comparisons on ZonedDateTime to be highly non-intuitive). We'd need something a bit more objective and/or widely supported to justify a behaviour change.

[mdickinson]

I'm going to close here. While changing the behaviour isn't completely out of the question, it would need (a) a clear proposal on how to deal with order comparisons and backwards compatibility, and (b) strong support from the community. A PEP is probably the best way forward, for anyone who wants to go this route.