bug#39248: format-time-string ignores user's preferred locale

[Paul W. Rankin <hello@paulwrankin.com>]

Thanks for looking into this for me.

> On 23 Jan 2020, at 6:38 pm, Paul Eggert <eggert@cs.ucla.edu> wrote:
> 
> Thanks for the bug report. I don't observe the problem on GNU/Linux; for example, the following shell command:
> 
> LC_ALL=en_AU.utf8 emacs -Q -batch -eval '(message "%s" (format-time-string "%x"))'

This outputs "01/23/20" for me. But I think this is because "utf8" vs "utf-8", e.g.

LC_ALL=en_au.utf-8 emacs -Q -batch -eval '(message "%s" (format-time-string "%x"))'
-> 23/01/2020

Which would indicate that macOS only recognises "utf-8" not "utf8".

LC_ALL=en_AU.utf8 date +%x
-> 01/23/20
LC_ALL=en_AU.utf-8 date +%x
-> 23/01/2020

I should note though that the issue only presents from Emacs.app i.e. when launched from Finder.

Even when launching Emacs.app via
/Applications/Emacs.app/Contents/MacOS/Emacs -Q
I can get the correct date.

It's solely when the app is launched from Finder i.e. outside the shell. AFAIK this means there's no way for me to launch Emacs.app outside of the shell with the -Q flag and so I moved my init files out of the way for a clean launch and reproduced that way.

I've also reproduced on Emacs.app versions 24 and 25. (It's actually an issue that has bothered me for years.)


> I suggest that you build Emacs with debug symbols and with optimization off (e.g., "make clean; make CFLAGS='-g3 -O0'"), and then run it under a debugger, and plant a breakpoint on the nstrftime function and then single-step and see what goes wrong. Something like this:
> 
> $ make clean
> $ make CFLAGS='-g3 -O0'
> $ gdb src/emacs
> (gdb) b nstrftime
> (gdb) r -Q -batch -eval '(message "%s" (format-time-string "%x"))'
> (gdb) n
> (gdb) n
> ...

I installed gdb and followed these steps, but I get a codesigning error; apparently in order to function on macOS, gdb requires some "code-signing" steps that are beyond my competency level.

Is there another way to test the strftime function?

Or, given that the issue is isolated to Emacs.app when launched outside of the shell environment, does that narrow it down at all?