PS C:\Users\Terry> py -3 -m test test_datetime
[1/1] test_datetime
test test_datetime failed -- Traceback (most recent call last):
  File "C:\Programs\Python 3.5\lib\test\datetimetester.py", line 1154, in test_strftime
    self.assertEqual(t.strftime(""), "") # SF bug #761337
ValueError: Invalid format string

Same result 3 times.

Looks like something related to issue 24917.

I can reproduce.  I'm bewildered as to why none of the buildbots are complaining about this.

Interestingly, the re-run performed by regrtest's '-w' flag did not fail.

Maybe errno needs to be explicitly cleared before calling strftime or else we're seeing someone else's EINVAL?

(In the C code I mean, not in the test.)

Yes, errno should always be cleared before use (in C99 at least,
not sure what the crt does).

> errno should always be cleared before use (in C99 at least,
> not sure what the crt does).

The CRT's strftime doesn't clear errno. I suggested clearing it in issue 25029, msg250215.

I guess when I said I'd done "exactly" what you suggested I misread that part... whoops.

This is a pretty nasty bug to workaround... do we have any way for a user to clear errno from their own code?

Clearing is easy: errno = 0; :)


C library functions are not supposed to set errno to 0 by
themselves (C99: paragraph 7.5).

I get that part.

Is there a way people can set errno to zero from Python code? Or do we need to ship 3.5.1 already?

It's common in Modules/posixmodule.c to set errno to 0 before calling a C function, especially when "errno != 0" is checked after the call (because it's the only way to check if the function failed?).

Given all the changes in the windows support in 3.5, I will not be at all surprised if we need to spin 3.5.1 much more quickly than we normally would in any case.

Steve, sorry if I misunderstand you: My point (and eryksun's)
was that errno is currently not cleared before the call to
format_time() in

  Modules/timemodule.c:657


I didn't look at this issue in depth, just pointing out a
possible cause.

Argh, finally I got it: You suggested that Python users work
around this in 3.5 by setting errno from the interpreter.

I think it's better to release 3.5.1 early.

> Is there a way people can set errno to zero from Python code? 
> Or do we need to ship 3.5.1 already?

The only the thing that comes to mind is using ctypes based on the CRT's implementation of errno:

    import ctypes
    import errno
    import time

    ucrtbase = ctypes.CDLL('ucrtbase')
    ucrtbase._errno.restype = ctypes.POINTER(ctypes.c_int)
    c_errno = ucrtbase._errno().contents

    >>> time.strftime('')
    ''
    >>> c_errno.value = errno.EINVAL; time.strftime('')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: Invalid format string

But it should go without saying that clearing errno from Python isn't reliable considering how much code executes between Python statements. It needs to be cleared right before call strftime, and optionally the old value needs to be saved first in order to restore it, if you're concerned about that.

I'm not worried about preserving it - strftime is supposed to be a very thin wrapper around the underlying strftime.

I think David's right and we'll be shipping 3.5.1 pretty soon regardless (though a lot of the issues seem to be due to changed installation locations and have existing for a long time, just that the people who regularly change the defaults apparently haven't reported them).

Patch attached. I haven't been able to repro the issue locally without the fix, but it seems indisputably correct behavior.

We could also skip most of the function for an empty format string and save ourselves a lot of work. That would avoid the ambiguous returned "is it zero-length or is it an error" value.

(The fix is indisputably correct, is what I meant.)

+#if defined _MSC_VER && _MSC_VER >= 1400 && defined(__STDC_SECURE_LIB__)
+        errno = 0;
+#endif

This code is too complex. Please remove the #if and always set errno to 0, on any platform!

We don't check errno on any other platform.

> We don't check errno on any other platform.

Oh ok. The code becomes more and more verbose because of Windows :-(

Arguably it's because of the platforms that don't reliably set errno. (I don't know exactly which those are, but I'm not about to enable it everywhere right now. If someone else wants to do it and deal with the fallout they're welcome.)

New changeset aa6b9205c120 by Steve Dower in branch '3.5':
Issue #25092: Fix datetime.strftime() failure when errno was already set to EINVAL.
https://hg.python.org/cpython/rev/aa6b9205c120