Skip to content

datetime.strftime strings can be terminated by "\x00" literals #124531

Description

@pganssle

Bug report

Bug description:

Apparently the strftime parser treats \x00 as "end of string" in the format code, and the remainder of the string is ignored:

>>> from datetime import datetime
>>> datetime(2024, 9, 25).strftime("\x00%Y-%m-%d")
""

I would have expected:

>>> from datetime import datetime
>>> datetime(2024, 9, 25).strftime("\x00%Y-%m-%d")
"\x002024-09-25"

Discovered this when adding some hypothesis tests for strptime/strftime. I suspect again that if you include a null character in your datetime format string you should expect something to act weird as hell about it, but we should probably fix this anyway if it's not too costly.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

Activity

  1. JelleZijlstra commented on Sep 25, 2024

    @JelleZijlstra
    Member

    I guess this makes sense if we create a C string and pass this to the C strftime function. Perhaps we should raise an error in our code if we encounter a null character in the format string.

  2. pganssle commented on Sep 25, 2024

    @pganssle
    MemberAuthor

    I guess this makes sense if we create a C string and pass this to the C strftime function. Perhaps we should raise an error in our code if we encounter a null character in the format string.

    I think we can just escape them and then un-escape them before returning, no?

    We handle this just fine in datetime.fromisoformat:

    >>> datetime.now().isoformat(sep="\x00")
    '2024-09-25\x0013:22:39.621972'
    >>> datetime.fromisoformat(datetime.now().isoformat(sep="\x00"))
    datetime.datetime(2024, 9, 25, 13, 22, 52, 309562)
  3. Mariatta commented on Sep 27, 2024

    @Mariatta
    Member

    I also think it shouldn't raise error in this case. My expectation is the strftime shouldn't care about anything that isn't datetime format specifier, so it should ignore the \x00 instead of treating it as end of string.

  4. added
    3.12only security fixes
    3.13only security fixes
    3.14bugs and security fixes
    on Oct 5, 2024
  5. added a commit that references this issue on Oct 5, 2024
  6. serhiy-storchaka commented on Oct 5, 2024

    @serhiy-storchaka
    Member

    There are many other bugs in strftime(), and I think that fixing this issue gives a key to fix #78662 and #52551.

  7. serhiy-storchaka commented on Oct 7, 2024

    @serhiy-storchaka
    Member

    This approach did not work on platforms without wstrftime() because PyUnicode_EncodeLocale() does not support embedded null characters. So I was forced to write more complex and generic patch that fixes also other issues. All that remains is to write the tests, I will do it tomorrow.

  8. added 2 commits that reference this issue on Oct 9, 2024
  9. added a commit that references this issue on Oct 17, 2024
  10. added 3 commits that reference this issue on Oct 17, 2024
  11. added a commit that references this issue on Oct 17, 2024
  12. added a commit that references this issue on Oct 17, 2024
  13. added a commit that references this issue on Jan 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

3.12only security fixes3.13only security fixes3.14bugs and security fixestype-bugAn unexpected behavior, bug, or error

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions