[Top][All Lists]

[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

> 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

> 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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]