This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mjsaah
Recipients belopolsky, eric.smith, matrixise, mjsaah, thatiparthy, xtreak
Date 2018-10-25.19:52:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
Did a little digging. Seems that there are two versions of the datetime
module, a C version (looks like an accelerator module) and a Py version.

Both define a wrap_strftime function that replace %z, %Z and %f format
codes before handing off to the timemodule.c code, where the actual
strftime function is called (aliased as format_time).

Here's the strange thing. The C datetime module raises a ValueError on a
dangling %, while the Python version does not. The C code can be seen here:
and the python version is here

So to summarize, it seems unnecessary to throw an error on a dangling % in
a higher-order module (_datetimemodule.c) when the lower-order module
(timemodule.c) doesn't do the check, and that lower-order module readily
accepts external input. This seems to be further corroborated by the fact
that the equivalent python version of the high-order module (
does not do the check either.

Let me know if I'm off base here, or if this is a fair assessment.

On Thu, Oct 25, 2018 at 2:35 PM Karthikeyan Singaravelan <> wrote:

> Karthikeyan Singaravelan <> added the comment:
> Michael: I understand the inconsistency but since there is a test that
> says ValueError is  platform dependent then making it as an intentional
> error there might be breakage. I am not against changing this but if it's
> done then it should be done with DeprecationWarning for 3.8 and then later
> removed on other versions.
> Some more information :
> Further, I looked into timemodule.c in CPython that says that it supports
> some common formats and "Other codes may be available on your platform.
> See documentation for the C library strftime function." . I looked into
> freebsd strftime there is an explicit comment if conversion char is
> undefined then the behavior is also undefined and to just print it out.
> Related issue that has the patch to an external implementation that refers
> to the same comment :
> Meanwhile datetime strftime uses wrap_strftime that defines the custom
> error message when format ends with raw % and does some more error
> reporting.
> # datetime strftime error :
> # Freebsd
> # Same comment on Apple's source :
> case '%':
> /*
> * X311J/88-090 ( if conversion char is
> * undefined, behavior is undefined. Print out the
> * character itself as printf(3) also does.
> */
> default:
>     break;
> Initially I thought this is the relevant code that is printing the '%' but
> looking at the loop itself if the first character is "%" followed by '\0'
> indicating that it's just '%' then it breaks out of the loop and just
> returns '%' which I hope is happening on my system. I don't think the above
> case of printing out the character itself in the comment i.e. "%" is done
> here.
> The above are based on my limited knowledge of C though so feel free to
> correct me if I am wrong on the above or took it out of context. So maybe
> this can be documented that for time.strftime the behavior is undefined
> when the conversion char is undefined and is based on the underlying
> operating system internals. Also a note that time.strftime with just '%' is
> system dependent meanwhile datetime.strftime '%' produces a ValueError. I
> think the same is noted in the test that this platform dependent depending
> on the implementation of strftime like in Windows. So if we are going to
> make '%' as an error from Python like datetime.strftime in time.strftime
> too then lies the breakage since Python behaves different from the
> underlying OS strftime implementation it uses for time module.
> Hope it helps and maybe someone else with a better understanding of C has
> a better explanation.
> ----------
> _______________________________________
> Python tracker <>
> <>
> _______________________________________
Date User Action Args
2018-10-25 19:52:02mjsaahsetrecipients: + mjsaah, belopolsky, eric.smith, matrixise, thatiparthy, xtreak
2018-10-25 19:52:02mjsaahlinkissue35066 messages
2018-10-25 19:52:02mjsaahcreate