This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: datetime subject to rounding?
Type: Stage:
Components: Library (Lib) Versions: Python 3.9, Python 3.8, Python 3.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: dfortunov, ewjoachim, piro, rhettinger
Priority: normal Keywords:

Created on 2021-10-02 17:01 by piro, last changed 2022-04-11 14:59 by admin.

Messages (4)
msg403059 - (view) Author: Daniele Varrazzo (piro) * Date: 2021-10-02 17:01
I found two datetimes at difference timezone whose difference is 0 but which don't compare equal.

Python 3.9.5 (default, May 12 2021, 15:26:36) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime as dt
>>> from zoneinfo import ZoneInfo
>>> for i in range(3):
...     ref = dt.datetime(5327 + i, 10, 31, tzinfo=dt.timezone.utc)
...     print(ref.astimezone(ZoneInfo(key='Europe/Rome')) == ref.astimezone(dt.timezone(dt.timedelta(seconds=3600))))
... 
True
False
True
>>> for i in range(3):
...     ref = dt.datetime(5327 + i, 10, 31, tzinfo=dt.timezone.utc)
...     print(ref.astimezone(ZoneInfo(key='Europe/Rome')) - ref.astimezone(dt.timezone(dt.timedelta(seconds=3600))))
... 
0:00:00
0:00:00
0:00:00

Is this a float rounding problem? If so I think it should be documented that datetimes bewhave like floats instead of like Decimal, although they have finite precision.
msg403062 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2021-10-02 19:39
Related:  https://bugs.python.org/issue44831
msg403078 - (view) Author: Joachim Jablon (ewjoachim) * Date: 2021-10-03 07:16
It may or it may not be obvious to some, but in year 5328, October 31st is the last Sunday of October, which in Rome, as in the rest of EU, according to the 202X rules, means it’s the day we shift from summer time (in Rome UTC+2) to standard time (in Rome UTC+1). The shift supposedly happens at 3AM where it’s 2AM, so not at midnight, but the proximity to a daylight shift moment raises some eyebrows. This could explain why it doesn’t happen on the year before or after. (I’m curious if it happens on year 5334 which has the same setup, but I cannot check at the moment)
msg405284 - (view) Author: Daniele Varrazzo (piro) * Date: 2021-10-28 22:37
Considering that I have found another pair of dates failing equality, and they are too on the last Sunday of October, the hypothesis of rounding in timezone code starts to look likely....

Python 3.7.9 (default, Jan 12 2021, 17:26:22) 
[GCC 8.3.0] on linux

>>> import datetime, backports.zoneinfo
>>> d1 = datetime.datetime(2255, 10, 28, 7, 31, 21, 393428, tzinfo=datetime.timezone(datetime.timedelta(seconds=27060)))
>>> d2 = datetime.datetime(2255, 10, 28, 2, 0, 21, 393428, tzinfo=backports.zoneinfo.ZoneInfo(key='Europe/Rome'))
>>> d1 - d2
datetime.timedelta(0)
>>> d1 == d2
False

Added Python 3.7 to the affected list.
History
Date User Action Args
2022-04-11 14:59:50adminsetgithub: 89510
2021-10-28 22:37:10pirosetmessages: + msg405284
versions: + Python 3.7
2021-10-03 11:02:16dfortunovsetnosy: + dfortunov
2021-10-03 07:16:24ewjoachimsetnosy: + ewjoachim
messages: + msg403078
2021-10-02 19:39:36rhettingersetnosy: + rhettinger
messages: + msg403062
2021-10-02 17:01:42pirocreate