[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Change by Raymond Hettinger : -- nosy: +brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Paul Ganssle added the comment: I've left a mostly finished PR on #8983, but I've decided it's not really worth continuing to work on. Anyone can feel free to take it and run with it if they want to implement the fix for this. As Alexey mentions, that PR indeed already fixes this bug, I

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Alexey Izbyshev added the comment: > if we can't make assertions about the behavior of strftime outputs, I think > it makes it hard to prevent regressions. Ironically, some of the changes we may have to make to fix time.strftime() inconsistencies may appear like regressions to some users.

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Paul Ganssle added the comment: @izbyshev That's totally fair and I wouldn't want to make it a condition of merging the existing fixes - I've already made great progress in fixing the time.strftime part as well. The main reason it relates here is that I generally find the tests to be among

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Alexey Izbyshev added the comment: @p-ganssle > I'm finding it very difficult to reconcile these things. Paul, this issue was only about reconciling C and Python implementations of datetime module -- not fixing time.strftime(), which both of them delegate to. While the latter is certainly

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

STINNER Victor added the comment: > Because caring of surrogates, Before* -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

STINNER Victor added the comment: Because caring of surrogates, I would prefer to first fix time.strftime() and time.strptime() for legit time zone names. Currently, Python uses the C function strfime() because the string produced by wcsftime() cannot be parsed later. We should use the

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Paul Ganssle added the comment: I'm finding it very difficult to reconcile these things. I'm not entirely sure, but we may need to take a performance hit in normal strftime if we want to make this work with surrogate characters, which really does not appeal to me (though we can certainly

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Change by Paul Ganssle : -- keywords: +patch pull_requests: +8457 stage: -> patch review ___ Python tracker ___ ___

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

New submission from Alexey Izbyshev : The C datetime implementation uses PyUnicode_AsUTF8AndSize() in wrap_strftime() and rejects strings containing surrogate code points (0xD800 - 0xDFFF) since they can't be encoded in UTF-8. On the other hand, the pure-Python datetime implementation