You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
time.localtime(float("NaN")) does not raise a ValueError on all platforms #70856
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=<Date2019-10-29.11:12:36.394>created_at=<Date2016-03-30.07:17:23.433>labels= ['extension-modules', 'interpreter-core', 'type-bug']
title='time.localtime(float("NaN")) does not raise a ValueError on all platforms'updated_at=<Date2019-10-29.11:12:36.392>user='https://github.com/gpshead'
time.localtime(float("NaN")) raises a ValueError on x86_64 using the few compilers I have tested it with. (this makes sense)
>>> time.localtime(float("NaN"))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: (75, 'Value too large for defined data type')
On an arm and arm64 system, it does not and treats NaN as 0. (nonsense!)
The root of this problem appears to be the (potentially questionable? I'll ask a C compiler person...) code in Python/pytime.c's (3.x) Modules/timemodule.c's (2.7) double to time_t conversion function.
I'm not sure what it does is supposed to be well defined behavior with NaN...
The easy fix is to add:
#include<math.h>
and
add || isnan(x) || isinf(x) to the check that raises a ValueError in
potentially questionable? I'll ask a C compiler person...
Questionable indeed. Attempting to cast a NaN to an integer type results in undefined behaviour. Unfortunately, so does attempting to cast any double value that's outside the range represented by the time_t type, so the questionability extends beyond just the NaN handling.
New changeset a4baf1c by Mariatta (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-26669: Fix nan arg value error in pytime.c (GH-3085) (GH-3467) a4baf1c
Activity
gpshead commentedon Mar 30, 2016
time.localtime(float("NaN")) raises a ValueError on x86_64 using the few compilers I have tested it with. (this makes sense)
On an arm and arm64 system, it does not and treats NaN as 0. (nonsense!)
The root of this problem appears to be the (potentially questionable? I'll ask a C compiler person...) code in Python/pytime.c's (3.x) Modules/timemodule.c's (2.7) double to time_t conversion function.
I'm not sure what it does is supposed to be well defined behavior with NaN...
The easy fix is to add:
and
add || isnan(x) || isinf(x) to the check that raises a ValueError in
https://hg.python.org/cpython/file/4c903ceeb4d1/Python/pytime.c#l149 (3.x)
https://hg.python.org/cpython/file/2.7/Modules/timemodule.c#l102 (2.7)
Along with a relevant assertRaises(ValueError) unittest for NaN, inf and -inf in test_time.py.
mdickinson commentedon Aug 14, 2017
Questionable indeed. Attempting to cast a NaN to an integer type results in undefined behaviour. Unfortunately, so does attempting to cast any double value that's outside the range represented by the
time_ttype, so the questionability extends beyond just the NaN handling.vstinner commentedon Aug 31, 2017
I like PR 3085 to raise explicitly a ValueError with an helpful error message.
vstinner commentedon Sep 8, 2017
New changeset 829dacc by Victor Stinner (Han Lee) in branch 'master':
bpo-26669: Fix nan arg value error in pytime.c (bpo-3085)
829dacc
vstinner commentedon Sep 8, 2017
For Python 2.7, you have at least to fix these 2 functions: parse_time_double_args(), _PyTime_DoubleToTimet().
Mariatta commentedon Sep 9, 2017
New changeset a4baf1c by Mariatta (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-26669: Fix nan arg value error in pytime.c (GH-3085) (GH-3467)
a4baf1c
Mariatta commentedon Sep 9, 2017
This has been backported to 3.6.
Is backport to 2.7 needed? If not we'll close the issue.
vstinner commentedon Jan 10, 2019
I wrote PR 11507 to raise ValueError rather than OverflowError for -inf and +inf.
isidentical commentedon Oct 29, 2019
Victor's PR 11507 is closed, what actions are going to be taken next? Close the issue as Mariatta said?
vstinner commentedon Oct 29, 2019
Python 2 users have this bug since 2010, I think that it's fine to not fix it. Python 2 support ends at the end of the year. I close the issue.
The issue has been fixed in Python 3.6 and newer.