There seems to be a platform difference in the way stftime handles 
unknown format codes.

In OSX Python removes the percentage sign from the returned string when the format code is unknown. In Linux it leaves it.

Look at the following example:

This is Python 3.1.2 in Ubuntu:

    Python 3.1.2 (r312:79147, Apr 15 2010, 15:35:48) 
    [GCC 4.4.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import datetime
    >>> datetime.datetime.now().strftime("%q")
    '%q'

And this is Python 3.1.2 on Max OSX:

    Python 3.1.2 (r312:79147, Sep  9 2010, 11:11:24) 
    [GCC 4.2.1 (Apple Inc. build 5664)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import datetime
    >>> datetime.datetime.now().strftime("%q")
    'q'

I've gotten the same result in 2.5, 2.6 and 3.1.

FYI, this broke some code that parsed the same string first with strftime, and then used string interpolation (The mac version
deleted all percentage signs before '('):

    >>> datetime.datetime.now().strftime("%Y - %(foobar)s") % {"foobar": "egg"}

This does not work in OSX.

This is because of differences in GNU and BSD C stdlib; I get the same results using the BSD and GNU versions of `date`.

    $ date +"%q"

What does Python typically do in cases like this?

Python's strftime is a thin wrapper around the system strftime.  This means, for example, that a slightly different set of % codes is supported on windows vs linux.  So, from Python's point of view this is at *most* a doc bug.

That said, I think there have been some rumblings about writing our own strftime, but I don't know if anyone is serious about it.

> I think there have been some rumblings about writing our own strftime

Yes, see issue #3173.

Another related issue is #9650 which discusses how to properly document strftime codes.

I think supporting different specifiers is one thing, dropping the % character is another.  This is how I understand the bug report.

But if it is a bug, it is a bug in OS/X, not in Python.  Python could potentially fix it for python programs by providing our own strftime, but until someone does that the best we can do is a doc mention of this platform quirk.

Ah, I understand your first reply now.  Thanks.  Agreed on all your points.

I've filed #9451707 about this in Apple's bug tracker.

BTW. I don't think this is a platform bug, neither the manpage nor the unix specification at <http://pubs.opengroup.org/onlinepubs/007908799/xsh/strftime.html> specify what happens when you use an undocumented format specifier.

Right, that's why I said "if it is a bug" :)

FreeBSD has the same behavior, so I'd actually prefer that Apple not "fix" this.  It would be nice if FreeBSD did and Apple adopted it, though, since only dropping the % is the least intuitive approach to handling unknown codes I can think of.  Is Apple tracking FreeBSD development at all these days, or are they a true fork now?

I'm not sure if Apple's tracking FreeBSD, but they at the very least heavily borrow code (see <http://opensource.apple.com/source/Libc/Libc-594.9.4/> for libc)

`strftime` does not, indeed, seem to define what behaviour it is supposed to do when given non-supported format characters. Under Windows, in fact, it will crash the runtime (see: issue #10762).

Santoso Wijaya wrote:
> 
> Santoso Wijaya <santoso.wijaya@gmail.com> added the comment:
> 
> `strftime` does not, indeed, seem to define what behaviour it is supposed to do when given non-supported format characters. Under Windows, in fact, it will crash the runtime (see: issue #10762).

According to POSIX, it is defined to be undefined:

"""
       If a conversion specification does not correspond to any of  the  above,  the
       behavior is undefined.
"""

Of course, crashing the runtime is not a good way to interpret this ;-)

Yeah, I meant undefined. I looked that up when writing a patch for issue #10762.

Correction: It *used to* crash on Windows, before the patch was applied.

This issue was created 11 years ago today. Let's celebrate its anniversary by resolving it!

New changeset e86bcfa58080f152f242c756f625f4015671f168 by Irit Katriel in branch 'main':
bpo-9811: [doc] strftime handling of unsupported format specifiers is platform dependent (GH-28264)
https://github.com/python/cpython/commit/e86bcfa58080f152f242c756f625f4015671f168

New changeset 897e5aae748180acf8d546d14aeacaf02600fff9 by Miss Islington (bot) in branch '3.10':
bpo-9811: [doc] strftime handling of unsupported format specifiers is platform dependent (GH-28264) (GH-28277)
https://github.com/python/cpython/commit/897e5aae748180acf8d546d14aeacaf02600fff9

New changeset baeaaecb8a97033bc2d07d51442cc8b1f89d410d by Miss Islington (bot) in branch '3.9':
bpo-9811: [doc] strftime handling of unsupported format specifiers is platform dependent (GH-28264) (GH-28278)
https://github.com/python/cpython/commit/baeaaecb8a97033bc2d07d51442cc8b1f89d410d

Is there anything else you wanted to do here, Irit?

No, I think we're good. Thanks.

New changeset b1873d1e24ed5ef39f37ca3090c2f0c2b34ce23f by Pablo Galindo (Miss Islington (bot)) in branch '3.10':
bpo-9811: [doc] strftime handling of unsupported format specifiers is platform dependent (GH-28264) (GH-28277)
https://github.com/python/cpython/commit/b1873d1e24ed5ef39f37ca3090c2f0c2b34ce23f