GNU bug report logs - #79296
30.2; format-time-string returns wrongly encoded string in MS Windows Japanese with cp65001 beta config

Previous Next

Full log

Message #32 received at 79296 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Eli Zaretskii <eliz <at> gnu.org>, Corwin Brust <corwin <at> bru.st>
Cc: 79296 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, shingo.fg8 <at> gmail.com
Subject: Re: bug#79296: 30.2;
 format-time-string returns wrongly encoded string in MS Windows Japanese with
 cp65001 beta config
Date: Tue, 26 Aug 2025 00:34:16 +0200

> * Actions:
>   - Bruno: Add a unit test for nstrftime in w32utf8 mode.

Done. The test verifies that nstrftime produces the Japanese weekday
in UTF-8 encoding. It passes, provided the locale name used is
"Japanese_Japan.65001", *not* "Japanese_Japan.932".

Eli Zaretskii wrote:
> > * Hypothesis 1:
> >   The Gnulib support included in Emacs 30.2 is older than 2024-12-23.
> 
> How does one know?  I see Paul last ran admin/merge-gnulib on the
> emacs-30 release branch on Aug 2, 2025

With Paul's newer comment, this hypothesis is falsified.

> > * Hypothesis 2:
> >   The Gnulib support included in Emacs 30.2 misses the commits
> >   https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=927a70e0853345315570f051fd6996cfeb7b4d96
> >   https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=9f7ff4f423cd805866cd4edef806c32393621df0
> >   https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=00211fc69c926d6c8f6e3f3cf1d8802623db2af9
> >   https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=8e795a8d9f8c3269a3d30d0d1adbaf0ea9ad4a84
> 
> These commits are in Gnulib files that are not used in Emacs.  What
> are their effects on the issue at hand, which is the non-ASCII strings
> produced by Gnulib's nstrftime?

That's most likely the problem, then. For Emacs, the third commit should be
the essential one: It forces a setlocale() argument that ends in ".65001",
thus telling the Microsoft UCRT that you want the UTF-8 environment.

> >   - This UTF-8 system codepage is only supported with Microsoft UCRT, not
> >     with the MSVCRT. At compile time, this configuration can be tested via
> >     '#ifdef _UCRT'. (This is true for both the mingw and the MSVC toolchains.)
> 
> What is it in UCRT that is required for Gnulib to support the UTF-8
> system codepage on Windows, in particular for strftime?  IOW, what
> does the UCRT implementation of libc does that the MSVCRT one doesn't,
> that affects this aspect of Gnulib's strftime?

Microsoft's UCRT has many changes compared to MSVCRT, probably worth of 10 years
of development. Support for the UTF-8 environment is certainly only one of
the many improvements.

So, the remaining hypotheses are:

* Hypothesis 2:
  The string that Emacs passes to the setlocale() function does not end in ".65001".

* Hypothesis 3:
  The Emacs 30.2 binaries are linked with MSVCRT, not with UCRT.
  -> Corwin?

Bruno

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.