Installed http://www.python.org/ftp/python/2.7.1/python-2.7.1.amd64.msi
on Windows 7, x64 into C:\Python27

C:\>\Python27\python.exe
Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime('%f')

Dialog raises: "Python.exe has stopped working"

Note that this is a regression relative to 2.6, where the same call returns '' (which is different from what it returns on linux, where the result would be '%f', or OSX, where the result would be 'f').  (Tests done on windows XP using pythons installed from the python.org installers.)

My guess is that the difference between python 2.6 and python 2.7+ is issue 4804.  I'm therefore adding the nosy list from that issue to this one.

For the OP's benefit: my guess is that this is a bug in the Microsoft C runtime, but we probably need to provide a workaround for it in Python.

Agree that the patches from issue 4804 and wrapping strftime() to catch the invalid_parameter call would fix this:

windbg trace:
0:000> k
Child-SP          RetAddr           Call Site
00000000`0021f328 000007fe`fdbb27cf ntdll!ZwTerminateProcess+0xa
00000000`0021f330 00000000`6ec24eec KERNELBASE!TerminateProcess+0x2f
00000000`0021f360 00000000`6ec24fc0 MSVCR90!invoke_watson+0x11c
00000000`0021f950 00000000`6ec11f5d MSVCR90!invalid_parameter+0x70
00000000`0021f990 00000000`6ec11fcd MSVCR90!Gettnames+0xebd
00000000`0021fa30 00000000`1e062e29 MSVCR90!strftime+0x15
00000000`0021fa70 00000000`1e0bff79 python27!PyTime_DoubleToTimet+0x5f9
00000000`0021fae0 00000000`1e10f084 python27!PyCFunction_Call+0x69
00000000`0021fb10 00000000`1e112834 python27!PyEval_GetGlobals+0x944
00000000`0021fb70 00000000`1e114039 python27!PyEval_EvalFrameEx+0x36a4
00000000`0021fc60 00000000`1e1140d9 python27!PyEval_EvalCodeEx+0x7e9
00000000`0021fd10 00000000`1e1400ca python27!PyEval_EvalCode+0x29
00000000`0021fd70 00000000`1e1417f6 python27!PyErr_Display+0x40a
00000000`0021fda0 00000000`1e14235e python27!PyRun_InteractiveOneFlags+0x1c6
00000000`0021fe10 00000000`1e1423d5 python27!PyRun_InteractiveLoopFlags+0xce
00000000`0021fe40 00000000`1e0443d9 python27!PyRun_AnyFileExFlags+0x45
00000000`0021fe70 00000000`1d00119e python27!Py_Main+0x8e9
00000000`0021ff30 00000000`777bf56d python+0x119e
00000000`0021ff60 00000000`779f3021 kernel32!BaseThreadInitThunk+0xd
00000000`0021ff90 00000000`00000000 ntdll!RtlUserThreadStart+0x21

I verified problem with 3.2b1 on 32-bit winxp machine.
IDLE restarts after pythonw crashes.

There does not seem to be any mention of what an ANSI behavior should be upon encountering a non-supported format string. Hence, perhaps, the discrepancy among different platforms.

I don't think this is a Windows "bug" per se, because the behavior is undefined in the standards. The burden is up to us to validate the format string inputted [w]strftime and currently, our code mistakenly clears "%f" as valid.

I'm attaching a patch against 2.7 branch.

Wrong filename. Attaching again: against 2.7 and 3.1 branches.

New changeset 2ca1bc677a60 by Senthil Kumaran in branch '3.1':
Issue #10762: Guard against invalid/non-supported format string '%f' on Windows. Patch Santoso Wijaya.
http://hg.python.org/cpython/rev/2ca1bc677a60

New changeset 1320f29bcf98 by Senthil Kumaran in branch '2.7':
Issue #10762: Guard against invalid/non-supported format string '%f' on Windows. Patch Santoso Wijaya.
http://hg.python.org/cpython/rev/1320f29bcf98

Fixed it in relevant branches. I had to add condition around the test to verify that platform was win because this is unique to windows only. Thanks.

The problem still exists in 3.4 and 3.5 a4


Unhandled exception in thread started by

Majeed, the fixes for this issue were released several years ago and the issue has been closed.  Comments on it will likely be ignored.  If you believe there is a problem in the current versions of Python 3 (3.4.3) or Python 2 (2.7.9), please open a new issue with appropriate supporting documentation of how to reproduce the problem (including platforms and versions used) and any resulting tracebacks.