[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35920: strftime incorrectly assumes that nstrftime will produce UTF-
From: |
Ludovic Courtès |
Subject: |
bug#35920: strftime incorrectly assumes that nstrftime will produce UTF-8 |
Date: |
Tue, 02 Jul 2019 11:07:01 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
Hi Mark,
Mark H Weaver <address@hidden> skribis:
>> Mark H Weaver <address@hidden> skribis:
>>
>>> Here's a patch that might fix the problem, but I don't have time to test
>>> it right now.
>>
>> It works! :-) I wrote tests and pushed it as
>> ab2fd70ef1e36c6532128b73082809ef3c056556.
>
> On my system, I found that my proposed patch caused one of the existing
> tests to fail.
Which test? In commit ab2fd70ef1e36c6532128b73082809ef3c056556 I
modified the test that passes \u0100 to run in a UTF-8 locale, on the
grounds that the previous behavior was fragile: “raw bytes” of the input
string would be preserved, but they could be mixed with things like
month names in the current locale encoding. The result is rather
unpredictable.
> The problem is that if the format string includes characters that are
> not representable in the current locale encoding, it will fail. It
> seems to me that this could break existing code that currently works.
> User code that uses 'strftime' might never encode the resulting string
> in the locale encoding.
In theory yes, but I cannot think of a scenario where the previous
behavior would be “useful”, because it’s hard to even describe what it
means.
> I was planning to rewrite the code to scan for the '%' escapes
> ourselves, to call 'strftime' for each escape sequence (without
> including the surrounding text), and to concatenate the results.
I think we should deprecate ‘strftime’ and ‘strptime’: (srfi srfi-19)
provides similar functionality, it uses (ice-9 i18n) for the locale
stuff, and it has a better API.
Perhaps something we can do in 3.0?
Thanks,
Ludo’.