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

[Paul W . Rankin]

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?