The original issue was marked with a security bug but I haven't looked at the entire thread so we might consider it a simple bug fix

@picnixz

No it needs to be relabeled:

-versions -type-security +type-bug

C calls the Python implementation.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phraseI have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

Note: I'll review more this PR once I'm back because it will be easier when I'm on a laptop and not on mobile (so on Wednesday/Thursday)

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phraseI have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

And if you don't make the requested changes, you will be put in the comfy chair!

I have made the requested changes; please review again

Thanks for making the requested changes!

@pganssle,@picnixz: please review the changes made to this pull request.

I think my comments on how to organize the documentation were not clear enough, so rather than another round of back-and-forth, I went ahead and pushed some changes to the documentation directly.

Also, I realized that the summary of "reject non-ASCII digits" isn't quite right, because there are actually locales where codes like%c and%X will generate strings with non-ASCII digits, e.g.:

>>>fromdatetimeimportdatetime>>>importlocale;locale.setlocale(locale.LC_ALL,'fa_IR.utf8')>>>print(datetime.now().strftime('%x'))۲۵/۰۳/۲۶>>>print(datetime.now().strftime("c"))چهارشنبه ۲۶مارس ۲۵، ۱۰:۳۷:۵۱

And in fact in 3.14 we fixedstrptime to properly parse these, see#125406.

TBH, I'm a little apprehensive about so widely advertising this change, because part of the rationale for doing it is that support for this kind of thing was patchy in the first place, so it's better for it to eitherall work ornot work at all. Fixing a bug like that doesn't seem like the kind of thing that needs a What's New entry and a permanent log of the change in thedatetime documentation on the same level as API changes like changes to the function prototype.

Given that we're trying to improve locale support in other ways, I could imagine us adding support for these things more explicitly in the future, so I wonder if we want to set the expectation that this willnever work.

@StanFromIreland@picnixz Would one or both of you mind taking a look at my changes and seeing if you agree?

@serhiy-storchaka As the person who has been working on the locale improvements, any thoughts on this subject?

I think that formats like%Y should only accept ASCII digits, but%OY and%EY should accept non-ASCII digits (the set of accepted digits can depend on the locale). TheO andE prefixes are not yet officially supported in Python.strftime() may support them if the underlying C function support them (they are a part of the C and Posix standards now, but this depends on the version and platform).strptime() is implemented in Python and doesn't officially support them, but I added unofficial support for some directives).

Currently, a heuristic is used to determine the format for%c,%x and%X in terms of simpler directives. I added (unofficially) support of theO prefix to support non-ASCII digits and plan to disallow support of non-ASCII digits in directives without theO orE prefix, but this is a change which cannot be backported. I have not yet finished with changes which can be backported.

First, we need to add official support of theO andE prefixes (even if it is platform dependent). We need to usenl_langinfo() for this. Then we can disallow non-ASCII digits for directives without these prefixes.

Actually, I started to work onstrptime() andnl_langinfo() issues after seen this issue. Most of the work is already done, but please wait a little longer.

Also, I realized that the summary of "reject non-ASCII digits" isn't quite right, because there are actually locales where codes like %c and %X will generate strings with non-ASCII digits, e.g.:

Oh I wasn't aware of this so thank you for the corrections.

@pganssle friendly ping :-)