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
[Windows] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6 #73283
> C:\Python36\python.exe
Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime; datetime.datetime.fromtimestamp(42)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument
Sounds like it really is an OSError (that is, that the Windows OS is the source of the error). Whether or not we can or should do something about that is a separate question, though.
and it turns out there aren't any. I highly doubt any timezone is going to retroactively enable/disable DST during the epoch, so a potentially hacky fix is to just have a windows specific check for this value range.
I'm adding the people involved in PEP-495 to the nosy list so they can give their input.
I think we should just clip the negative lower probe value to 0 on Windows before passing it to local(). Also, if we still care about platforms with 32-bit time_t, we should check for over/under flow *before* calling local().
I've attached two patches that fix this behavior, one by simply foregoing the fold detection for this time range on windows (the patch that I'd argue is simpler and more readable)
And one that truncates the passed values to local to not be negative. This one would have been simple but unfortunately there's the complication that there are two local calls and additionally, the second one cannot be truncated to exactly 0 because then we incorrectly detect a fold for the timestamp 0.
I just ran the following script to check if there are any folds from timestamps [0, 86399] in any timezone.
Ammar, I am not sure pytz timezones support PEP-495 conventions. Can you repeat your experiment using the latest dateutil.tz or test.datetimetester.ZoneInfo from Python 3.6 test suit?
changed the title [-]datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6[/-][+][Windows] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6[/+]on Jun 28, 2018
New changeset 96d1e69 by Alexander Belopolsky (Ammar Askar) in branch 'master': bpo-29097: Forego fold detection on windows for low timestamp values (GH-2385) 96d1e69
New changeset 9736493 by Alexander Belopolsky (Miss Islington (bot)) in branch '3.7': bpo-29097: Forego fold detection on windows for low timestamp values (GH-2385) (GH-8466) 9736493
New changeset 6ea8a3a by Alexander Belopolsky (Ammar Askar) in branch '3.6':
[3.6] bpo-29097: Forego fold detection on windows for low timestamp values (GH-2385) (GH-8498) 6ea8a3a
Activity
pekkaklarck commentedon Dec 28, 2016
For example:
Works fine at least with Python 2.6-2.7 and 3.3-3.5. Only tested on Windows (missing deadsnakes for easy Linux testing).
I was also surprised to get OSError in general, but apparently fromtimestamp uses that instead of ValueError nowadays in some error situations.
SilentGhost commentedon Dec 29, 2016
This doesn't seem likely that it's anything to do with datetime, could you try reproducing it in repl?
ammaraskar commentedon Dec 29, 2016
Can recreate successfully on windows, but not on linux:
SilentGhost commentedon Dec 29, 2016
Cannot reproduce this with the tip on linux
bitdancer commentedon Dec 29, 2016
Sounds like it really is an OSError (that is, that the Windows OS is the source of the error). Whether or not we can or should do something about that is a separate question, though.
ammaraskar commentedon Dec 29, 2016
The 86,399 upperbound comes from this line (max_fold_seconds=86400):
https://github.com/python/cpython/blob/master/Modules/_datetimemodule.c#L4277-L4278
The bug is introduced as part of the fold detection in this commit: 56376ca
Window's locatime_s function gives an EINVAL error when time is less than 0. Which is where the OSError comes from.
https://msdn.microsoft.com/en-us/library/a442x3ye.aspx
ammaraskar commentedon Dec 29, 2016
I just ran the following script to check if there are any folds from timestamps [0, 86399] in any timezone.
and it turns out there aren't any. I highly doubt any timezone is going to retroactively enable/disable DST during the epoch, so a potentially hacky fix is to just have a windows specific check for this value range.
I'm adding the people involved in PEP-495 to the nosy list so they can give their input.
abalkin commentedon Dec 29, 2016
I think we should just clip the negative lower probe value to 0 on Windows before passing it to local(). Also, if we still care about platforms with 32-bit time_t, we should check for over/under flow *before* calling local().
ammaraskar commentedon Dec 30, 2016
I've attached two patches that fix this behavior, one by simply foregoing the fold detection for this time range on windows (the patch that I'd argue is simpler and more readable)
And one that truncates the passed values to local to not be negative. This one would have been simple but unfortunately there's the complication that there are two local calls and additionally, the second one cannot be truncated to exactly 0 because then we incorrectly detect a fold for the timestamp 0.
abalkin commentedon Jun 16, 2017
Ammar, I am not sure pytz timezones support PEP-495 conventions. Can you repeat your experiment using the latest dateutil.tz or test.datetimetester.ZoneInfo from Python 3.6 test suit?
See <http://dateutil.readthedocs.io/en/stable/tz.html\>.
ammaraskar commentedon Jun 24, 2017
Hey, sorry for the late response. I just ran:
tz uses your OS's zone info so also posting my distro version:
Debian 8.8 - 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64 GNU/Linux
And I got the same result, no timezone with folds in these range.
ammaraskar commentedon Jun 24, 2017
Created a github pull request for the recommended patch along with a test: #2385
jleclanche commentedon Dec 27, 2017
Anything holding up the PR? Looks good at a glance, would be nice to get this landed in time for 3.7.
[-]datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6[/-][+][Windows] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6[/+]abalkin commentedon Jul 25, 2018
New changeset 96d1e69 by Alexander Belopolsky (Ammar Askar) in branch 'master':
bpo-29097: Forego fold detection on windows for low timestamp values (GH-2385)
96d1e69
abalkin commentedon Jul 25, 2018
New changeset 9736493 by Alexander Belopolsky (Miss Islington (bot)) in branch '3.7':
bpo-29097: Forego fold detection on windows for low timestamp values (GH-2385) (GH-8466)
9736493
abalkin commentedon Jul 27, 2018
New changeset 6ea8a3a by Alexander Belopolsky (Ammar Askar) in branch '3.6':
[3.6] bpo-29097: Forego fold detection on windows for low timestamp values (GH-2385) (GH-8498)
6ea8a3a