GNU bug report logs -
#39248
format-time-string ignores user's preferred locale
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39248 in the body.
You can then email your comments to 39248 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Thu, 23 Jan 2020 03:54:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Paul W. Rankin" <hello <at> paulwrankin.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 23 Jan 2020 03:54:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Calling function (format-time-string "%x") will output incorrect time
string, ignoring user's preferred locale.
* Steps to reproduce:
1. ensure locale is correct with M-x getenv RET LANG RET
-> en_AU.UTF-8
2. M-: (format-time-string "%x") RET
-> "01/23/20"
3. repeat for env LC_TIME
* Expected results:
The format for %x as per the docs:
%x is the locale’s "preferred" date format.
en_AU locale's "preferred" date format should be DD/MM/YYYY:
"23/01/2020"
i.e. the same as output from shell:
$ locale
LANG="en_AU.UTF-8"
LC_COLLATE="en_AU.UTF-8"
LC_CTYPE="en_AU.UTF-8"
LC_MESSAGES="en_AU.UTF-8"
LC_MONETARY="en_AU.UTF-8"
LC_NUMERIC="en_AU.UTF-8"
LC_TIME="en_AU.UTF-8"
LC_ALL=
$ date +%x
23/01/2020
* Actual results:
"01/23/20"
GNU Emacs 27.0.60 (build 1, x86_64-apple-darwin19.2.0, NS appkit-1894.20
Version 10.15.2 (Build 19C57)) of 2020-01-18
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Thu, 23 Jan 2020 05:57:01 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
On January 23, 2020 5:48:16 AM GMT+02:00, "Paul W. Rankin" <hello <at> paulwrankin.com> wrote:
> Calling function (format-time-string "%x") will output incorrect time
> string, ignoring user's preferred locale.
>
> * Steps to reproduce:
>
> 1. ensure locale is correct with M-x getenv RET LANG RET
> -> en_AU.UTF-8
> 2. M-: (format-time-string "%x") RET
> -> "01/23/20"
> 3. repeat for env LC_TIME
>
> * Expected results:
>
> The format for %x as per the docs:
> %x is the locale’s "preferred" date format.
What is your value of system-time-locale?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Thu, 23 Jan 2020 05:57:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Thu, 23 Jan 2020 06:45:02 GMT)
Full text and
rfc822 format available.
Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
On Thu, Jan 23 2020, Eli Zaretskii wrote:
>
> What is your value of system-time-locale?
system-time-locale -> nil
So, this works:
(setq system-time-locale (getenv "LANG"))
(format-time-string "%x")
-> "23/01/2020"
But in the Elisp manual:
-- Variable: system-time-locale
This variable specifies the locale to use for formatting time
values. Changing the locale can cause messages to appear according
to the conventions of a different language. If the variable is
‘nil’, the locale is specified by environment variables in the
usual POSIX fashion.
So the issue appears to be instead that ^this doesn't seem to be
happening...
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Thu, 23 Jan 2020 06:45:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Thu, 23 Jan 2020 08:39:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 39248 <at> debbugs.gnu.org (full text, mbox):
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"))'
outputs "23/01/20", which is the same thing that the shell command
"LC_ALL=en_AU.utf8 date +%x" outputs. I don't have easy access to macOS so I'll
need your help to debug this.
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
...
This will help us see whether the bug is in Emacs or in the underlying strftime
function.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Thu, 23 Jan 2020 13:13:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 39248 <at> debbugs.gnu.org (full text, mbox):
Thanks for looking into this for me.
> On 23 Jan 2020, at 6:38 pm, Paul Eggert <eggert <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Thu, 23 Jan 2020 14:20:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 39248 <at> debbugs.gnu.org (full text, mbox):
> From: "Paul W. Rankin" <hello <at> paulwrankin.com>
> Cc: bug-gnu-emacs <at> gnu.org, 39248 <at> debbugs.gnu.org
> Date: Thu, 23 Jan 2020 16:44:11 +1000
>
> So, this works:
>
> (setq system-time-locale (getenv "LANG"))
> (format-time-string "%x")
> -> "23/01/2020"
>
> But in the Elisp manual:
>
> -- Variable: system-time-locale
> This variable specifies the locale to use for formatting time
> values. Changing the locale can cause messages to appear according
> to the conventions of a different language. If the variable is
> ‘nil’, the locale is specified by environment variables in the
> usual POSIX fashion.
>
> So the issue appears to be instead that ^this doesn't seem to be
> happening...
No, having system-time-locale as nil is perfectly normal. I asked the
question so we'd know whether that variable is part of the issue. It
doesn't seem to be, AFAIU.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Thu, 23 Jan 2020 18:06:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 39248 <at> debbugs.gnu.org (full text, mbox):
> From: Paul W. Rankin <hello <at> paulwrankin.com>
> Date: Thu, 23 Jan 2020 23:12:39 +1000
> Cc: 39248 <at> debbugs.gnu.org
>
> Or, given that the issue is isolated to Emacs.app when launched outside of the shell environment, does that narrow it down at all?
I guess that's yet another manifestation of the macOS deviant behavior
of Emacs.app, whereby it doesn't inherit environment variables from
the shell.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Thu, 23 Jan 2020 22:06:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 39248 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>> Or, given that the issue is isolated to Emacs.app when launched
>> outside of the shell environment, does that narrow it down at all?
>
> I guess that's yet another manifestation of the macOS deviant behavior
> of Emacs.app, whereby it doesn't inherit environment variables from
> the shell.
Rather, that macOS does not set up environment for applications
launched from Finder. I don't think that is an Emacs problem.
On GNU/Linux, my window manager runss from a login shell and so has a
correct environment for applications it launches.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Fri, 24 Jan 2020 03:18:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 39248 <at> debbugs.gnu.org (full text, mbox):
> On 24 Jan 2020, at 8:04 am, Glenn Morris <rgm <at> gnu.org> wrote:
>
> Eli Zaretskii wrote:
>
>>> Or, given that the issue is isolated to Emacs.app when launched
>>> outside of the shell environment, does that narrow it down at all?
>>
>> I guess that's yet another manifestation of the macOS deviant behavior
>> of Emacs.app, whereby it doesn't inherit environment variables from
>> the shell.
>
> Rather, that macOS does not set up environment for applications
> launched from Finder. I don't think that is an Emacs problem.
>
> On GNU/Linux, my window manager runss from a login shell and so has a
> correct environment for applications it launches.
It would probably be weird for macOS to ask the shell for environment variables when launched from the Finder. The relationship doesn't appear as the same as on GNU/Linux.
But OS-preferences aside, Emacs.app in macOS does correctly set the process-environment variable though, so these environment variables (including LANG) are available to Emacs, e.g. USER, TMPDIR, SHELL are a few that seem to be picked up without issue, so shouldn't the same be true of LANG?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Fri, 24 Jan 2020 07:36:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 39248 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 1/23/20 7:17 PM, Paul W. Rankin wrote:
> The relationship doesn't appear as the same as on GNU/Linux.
It's similar, in that one can launch apps in various ways (e.g., via Gnome)
without involving shell environment variables.
Looking into this a bit more, I see that Alan Third wrote a fix for this problem
(which is apparently quite a zoo in macOS, as Apple keeps changing how to set
environment variables!) into Emacs in master commit
2016-02-11T02:26:50Z!alan <at> idiocy.org. However, Emacs currently sets the LANG
environment variable in ns_init_locale *after* Emacs uses LANG to set the
LC_TIME locale, which is not what is wanted here. So, please try the attached
patch to master. You'll need to grab the latest master as I recently installed a
locale cleanup patch while looking into this mess.
If this patch doesn't work for you, perhaps you can write a small variant of it
that does work.
[0001-Propagate-NSLocale-into-Emacs-better.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Sat, 25 Jan 2020 09:37:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 39248 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jan 24 2020, Paul Eggert wrote:
> However, Emacs currently sets the LANG environment variable in
> ns_init_locale *after* Emacs uses LANG to set the LC_TIME locale,
> which is not what is wanted here. So, please try the attached patch to
> master.
Thank you, this patch works; Emacs.app launched from Finder on macOS now
gives:
(format-time-string "%x")
"25/01/2020"
GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin19.2.0, NS appkit-1894.20
Version 10.15.2 (Build 19C57)) of 2020-01-25
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Sat, 25 Jan 2020 11:19:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 39248 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jan 23, 2020 at 11:35:20PM -0800, Paul Eggert wrote:
> #ifdef HAVE_NS
> ns_pool = ns_alloc_autorelease_pool ();
> -#ifdef NS_IMPL_GNUSTEP
> - /* GNUstep stupidly resets our locale settings after we made them. */
> - fixup_locale ();
> -#endif
Hi Paul, this LGTM, but I’m just curious if you’re sure we don’t need
that code above any more?
Thanks!
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Sat, 25 Jan 2020 11:43:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 39248 <at> debbugs.gnu.org (full text, mbox):
> On 25 Jan 2020, at 9:18 pm, Alan Third <alan <at> idiocy.org> wrote:
>
> On Thu, Jan 23, 2020 at 11:35:20PM -0800, Paul Eggert wrote:
>> #ifdef HAVE_NS
>> ns_pool = ns_alloc_autorelease_pool ();
>> -#ifdef NS_IMPL_GNUSTEP
>> - /* GNUstep stupidly resets our locale settings after we made them. */
>> - fixup_locale ();
>> -#endif
>
> Hi Paul, this LGTM, but I’m just curious if you’re sure we don’t need
> that code above any more?
I have no idea sorry. Applying the patch and compiling was a new experience for me. If someone held a gun to my head I wouldn't even be sure it's C code...
Is there anything you'd like me to do with the Emacs.app to check it's kosher?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Sat, 25 Jan 2020 12:04:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 39248 <at> debbugs.gnu.org (full text, mbox):
On Sat, Jan 25, 2020 at 09:42:16PM +1000, Paul W. Rankin wrote:
>
> > On 25 Jan 2020, at 9:18 pm, Alan Third <alan <at> idiocy.org> wrote:
> >
> > On Thu, Jan 23, 2020 at 11:35:20PM -0800, Paul Eggert wrote:
> >> #ifdef HAVE_NS
> >> ns_pool = ns_alloc_autorelease_pool ();
> >> -#ifdef NS_IMPL_GNUSTEP
> >> - /* GNUstep stupidly resets our locale settings after we made them. */
> >> - fixup_locale ();
> >> -#endif
> >
> > Hi Paul, this LGTM, but I’m just curious if you’re sure we don’t need
> > that code above any more?
>
> I have no idea sorry. Applying the patch and compiling was a new
> experience for me. If someone held a gun to my head I wouldn't even
> be sure it's C code...
>
> Is there anything you'd like me to do with the Emacs.app to check
> it's kosher?
No, you’re good. I was actually talking to the other Paul who wrote
the patch. :)
--
Alan Third
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
You have taken responsibility.
(Sun, 26 Jan 2020 08:36:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
"Paul W. Rankin" <hello <at> paulwrankin.com>
:
bug acknowledged by developer.
(Sun, 26 Jan 2020 08:36:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 39248-done <at> debbugs.gnu.org (full text, mbox):
On 1/25/20 3:18 AM, Alan Third wrote:
> On Thu, Jan 23, 2020 at 11:35:20PM -0800, Paul Eggert wrote:
>> #ifdef HAVE_NS
>> ns_pool = ns_alloc_autorelease_pool ();
>> -#ifdef NS_IMPL_GNUSTEP
>> - /* GNUstep stupidly resets our locale settings after we made them. */
>> - fixup_locale ();
>> -#endif
>
> Hi Paul, this LGTM, but I’m just curious if you’re sure we don’t need
> that code above any more?
Although I don't use GNUstep and haven't tested the code, as I recall GNUstep
initializes itself on its first call (which is why the fixup_locale call was
there, as ns_alloc_autorelease_pool was the first call to GNUstep), and if so
then we don't need fixup_locale there anymore since we now call fixup_locale
earlier, just after calling ns_init_locale which calls NSLocale currentlocale
should cause GNUstep to initialize itself.
If I'm wrong feel free to put that code back in, but in the meantime I installed
the patch as-is, as Paul R. reports that it works for him.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39248
; Package
emacs
.
(Sun, 26 Jan 2020 10:27:01 GMT)
Full text and
rfc822 format available.
Message #58 received at 39248-done <at> debbugs.gnu.org (full text, mbox):
On Sun, Jan 26, 2020 at 12:35:31AM -0800, Paul Eggert wrote:
> On 1/25/20 3:18 AM, Alan Third wrote:
> > On Thu, Jan 23, 2020 at 11:35:20PM -0800, Paul Eggert wrote:
> > > #ifdef HAVE_NS
> > > ns_pool = ns_alloc_autorelease_pool ();
> > > -#ifdef NS_IMPL_GNUSTEP
> > > - /* GNUstep stupidly resets our locale settings after we made them. */
> > > - fixup_locale ();
> > > -#endif
> >
> > Hi Paul, this LGTM, but I’m just curious if you’re sure we don’t need
> > that code above any more?
>
> Although I don't use GNUstep and haven't tested the code, as I recall
> GNUstep initializes itself on its first call (which is why the fixup_locale
> call was there, as ns_alloc_autorelease_pool was the first call to GNUstep),
> and if so then we don't need fixup_locale there anymore since we now call
> fixup_locale earlier, just after calling ns_init_locale which calls NSLocale
> currentlocale should cause GNUstep to initialize itself.
>
> If I'm wrong feel free to put that code back in, but in the meantime I
> installed the patch as-is, as Paul R. reports that it works for him.
No, sounds reasonable. Thanks for the explanation.
--
Alan Third
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 23 Feb 2020 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 35 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.