[issue45347] datetime subject to rounding?

[Daniele Varrazzo]

Daniele Varrazzo  added the comment:

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.

--
versions: +Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45347] datetime subject to rounding?

[Daniel Fortunov]

Change by Daniel Fortunov :


--
nosy: +dfortunov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45347] datetime subject to rounding?

[Joachim Jablon]

Joachim Jablon  added the comment:

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)

--
nosy: +ewjoachim

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45347] datetime subject to rounding?

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Related:  https://bugs.python.org/issue44831

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45347] datetime subject to rounding?

[Daniele Varrazzo]

New submission from Daniele Varrazzo :

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.

--
components: Library (Lib)
messages: 403059
nosy: piro
priority: normal
severity: normal
status: open
title: datetime subject to rounding?
versions: Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com