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:
https://github.com/python/cpython/blob/3df85404d4bf420db3362eeae1345f2cad948a71/Modules/_datetimemodule.c#L1517-L1520
and the python version is here
https://github.com/python/cpython/blob/9e95eb0d609cee23e6c9915c0bef243585b8c14b/Lib/datetime.py#L196

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 (datetime.py)
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 <
report@bugs.python.org> wrote:

>
> Karthikeyan Singaravelan <tir.karthi@gmail.com> 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 : https://bugs.python.org/issue3173
>
> 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 :
> https://github.com/python/cpython/blob/9e95eb0d609cee23e6c9915c0bef243585b8c14b/Modules/_datetimemodule.c#L1518
>
> # Freebsd
> https://github.com/freebsd/freebsd/blob/277918494930ec3fb0c7fdbd4d35060a3bc6d181/lib/libc/stdtime/strftime.c#L572
> # Same comment on Apple's source :
> https://opensource.apple.com/source/Libc/Libc-166/string.subproj/strftime.c
>
>
> case '%':
> /*
> * X311J/88-090 (4.12.3.5): 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 <report@bugs.python.org>
> <https://bugs.python.org/issue35066>
> _______________________________________
>