Repository navigation
Enhancement Proposal: Standardized Support for Non-Zero-Padded Day and Month Formatting in datetime.strftime #137165
Description
Feature or enhancement
Proposal:
Python's datetime.datetime.strftime supports formatting directives for dates and times, such as %d for zero-padded days and %m for zero-padded months.
While there are platform-specific ways to get non-zero-padded day (%-d on Unix) or month (%-m), these do not work reliably across all platforms.. Particularly between Unix-like systems and Windows.
from datetime import datetime
dt = datetime(2025, 6, 6)
# On Unix:
dt.strftime("%-d. %-m. %Y") # '6. 6. 2025'
# On Windows:
dt.strftime("%-d. %-m. %Y") # Raises ValueErrorI understand that strftime relies on the underlying C library for formatting, which is probably why this behavior differs between platforms. That said, if it's not practical to change this at the core level, maybe there could be some kind of wrapper or Python-level normalization to make things more consistent across systems.
Currently this requires a workaround such as usage of .format directly on the datetime object.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response
Linked PRs
- gh-137165: Add non-zero-padded Windows support for
datetime.strftime#138982 - gh-137165: Add non-zero-padded Windows support for
datetime.strftime#139002 - gh-137165: Standardize non-zero-padded date formatting for
datetime.strftime#139088 - gh-137165: Unify
datetime.strftimebehavior for unsupported non-zero-padded specifiers #145018
Activity
pythongh-137165: Add non-zero-padded Windows support
pythongh-137165: Add non-zero-padded Windows support
pythongh-137165: Add non-zero-padded Windows support
pythongh-137165: Add non-zero-padded Windows support
pythongh-137165: Add non-zero-padded Windows support for
pythongh-137165: Add non-zero-padded Windows support for datetime.str…
pythongh-137165: Add non-zero-padded Windows support for datetime.str…
pythongh-137165: Add non-zero-padded Windows support for datetime.str…
pythongh-137165: Add non-zero-padded Windows support for datetime.str…
pythongh-137165: Add non-zero-padded Windows support for datetime.str…
pythongh-137165: Add non-zero-padded Windows support for datetime.str…
pythongh-137165: Add non-zero-padded Windows support for datetime.str…
pythongh-137165: Add non-zero-padded Windows support for datetime.str…
pganssle commentedon Sep 18, 2025
This seems reasonable to me. I don't really recall what the current stance is on adding this kind of compatibility — we certainly don't consider it a bug if there are different behaviors across different OSes due to the underlying
strftimeimplementation, but if it doesn't makestrftimeslower or add a lot of complexity, I don't see why we can't do it.@zooba @mhsmith @freakboy3742 Thoughts about this from a platform-support perspective (Windows, Android)?
freakboy3742 commentedon Sep 18, 2025
From a purely user experience perspective, I agree it would be desirable to not have OS-specific implementation details leak into the public API for a function in the Python standard library.
Assuming there's an efficient, non-complex implementation of this feature, I can't think of any reason it would be a problem from a cross platform support perspective. As long as any augmentation needed to satisfy the public API results in a strict superset of the default system behavior, I can't think of any way that it could backfire.
mhsmith commentedon Sep 18, 2025
I agree: looking at the surrounding code of #139088, we've already done similar things in the past for less-widely-supported format codes like
%ffor microseconds.zooba commentedon Sep 18, 2025
At least from the Windows POV, I'm inclined to say that the C Runtime isn't the same as the OS APIs, and so while I'm regularly against "make native APIs all behave like POSIX", I don't think that needs to extend to CRT functions like this.
So if there's a path to get to a unified
datetimeimplementation across all its functions,1 let's go for it. Otherwise, "strict superset" or at least "almost certainly not trying to be compatible with non-Python apps that use the CRT" are fine.Footnotes
timeis different, since those are mostly OS APIs, not CRT ones. ↩pythongh-137165: Echo non-ASCII after `%-` literally in C strftime
pythongh-137165: Only emulate `%-` for the documented numeric codes
pythongh-137165: Complete BSD support for non-zero-padded strftime
pythongh-137165: Emulate %- flag on all platforms for consistency