Dates equality check fails when a date is folded and the other is not

[ale-rinaldi]

Bug report

Bug description:

In the example I have two dates in the Europe/Rome format, representing 2:00 AM on a day with DST change. One of the dates is folded, the other is not.

from datetime import datetime
from zoneinfo import ZoneInfo

not_folded = datetime(2023, 10, 29, 2, 0, tzinfo=ZoneInfo("Europe/Rome"))
folded = datetime(2023, 10, 29, 2, 0, tzinfo=ZoneInfo("Europe/Rome"), fold=1)

print("Not folded date: ", not_folded.isoformat())
print("The folded date: ", folded.isoformat())

assert folded != not_folded

The two dates are different, as the isoformat() print shows, and they represent a different moment in time (one is 00:00 UTC, the other one is 01:00 UTC). However, the assert fails:

Not folded date:  2023-10-29T02:00:00+02:00
The folded date:  2023-10-29T02:00:00+01:00
Traceback (most recent call last):
  File "/Users/alerinaldi/prova.py", line 10, in <module>
    assert folded != not_folded
           ^^^^^^^^^^^^^^^^^^^^
AssertionError

Of course, this also applies to other situations where dates are compared: I discovered the issue while memoizing the result of a function based on dates using a dict.

from datetime import datetime
from zoneinfo import ZoneInfo

__memoized_dict = {}


def process_date(dt: datetime) -> int:
    return int(dt.timestamp())


def memoized_result(dt: datetime) -> int:
    if dt in __memoized_dict:
        return __memoized_dict[dt]
    res = process_date(dt)
    __memoized_dict[dt] = res
    return res


print(memoized_result(datetime(2023, 10, 29, 2, 0, tzinfo=ZoneInfo("Europe/Rome"))))
print(memoized_result(datetime(2023, 10, 29, 2, 0, tzinfo=ZoneInfo("Europe/Rome"), fold=1)))

The second call returns a wrong result.

CPython versions tested on:

3.12

Operating systems tested on:

macOS

[TooPercentMilk]

I'm a beginner contributor and would like to work on this issue. How should I go about this?

[erlend-aasland]

Please see the discussion in #116035. Perhaps we should close this as a duplicate.

[ale-rinaldi]

Yeah totally. #116035 has been opened after this one but it's far more complete and professionally reported. It also links this issue so it's still referenced if someone needs context.

I close this one.