Yes, sounds like a bug.  I'll fix it.

But should time.strftime allow a unicode format string as input in the
first place?  For backwards compatibility I'd say yes.  But.. Sane
output can not be guaranteed from time.strftime when given a unicode
format string if it contains multibyte characters that happen to have a
valid (bytewise) % format code in them within a multibyte character. 
Anyways the output is always byte string without a specified encoding so
giving it actual unicode characters as input is not advised (at least in
2.6, i didn't check 3.0).

there's an amusing comment in Modules/datetimemodule.c:

/* I sure don't want to reproduce the strftime code from the time module,
 * so this imports the module and calls it.  All the hair is due to
 * giving special meanings to the %z, %Z and %f format codes via a
 * preprocessing step on the format string.
...
*/
static PyObject * wrap_strftime(