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
View this message in rfc822 format
> Date: Tue, 26 Aug 2025 23:19:14 +0900
> From: Shingo Tanaka <shingo.fg8 <at> gmail.com>
> Cc: Bruno Haible <bruno <at> clisp.org>,
> corwin <at> bru.st,
> shingo.fg8 <at> gmail.com,
> eggert <at> cs.ucla.edu,
> 79296 <at> debbugs.gnu.org
>
> On Wed, 27 Aug 2025 05:18:34 +0900,
> Eli Zaretskii wrote:
> >
> > However, since this is Emacs, Shingo Tanaka could test this by setting
> > the Lisp variable system-time-locale to the string
> > "Japanese_Japan.65001" and repeating the test presented at the
> > beginning of this discussion. Assuming that the build is a UCRT build
> > (Corwin?), this should fix the problem, if your analysis is correct.
>
> Here is the result. Unfortunately it doesn't fix the issue.
>
> (setq system-time-locale "Japanese_Japan.65001")
> "Japanese_Japan.65001"
>
> (format-time-string "%y,%d,%m %A" (date-to-time (concat "2025,1,Jan")))
> "25,01,01 \220\205\227j\223\372"
OK, now let's try to establish whether your Emacs was linked against
UCRT or MSVCRT. If you have objdump.exe (part of Binutils) installed,
please do
objdump /path/to/emacs.exe | fgrep "DLL Name"
and see if the output includes msvcrt.dll (case-insensitive) or
ucrtbase.dll.
If you don't have objdump, try the dependency walker
(https://www.dependencywalker.com/) instead. Or Process Explorer with
its lower panel set to show DLLs. Look for msvcrt.dll or ucrtbase.dll.
Thanks.
This bug report was last modified 21 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.