* bug#39248: format-time-string ignores user's preferred locale
@ 2020-01-23 3:48 Paul W. Rankin
2020-01-23 5:56 ` Eli Zaretskii
2020-01-23 8:38 ` Paul Eggert
0 siblings, 2 replies; 16+ messages in thread
From: Paul W. Rankin @ 2020-01-23 3:48 UTC (permalink / raw)
To: 39248
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
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#39248: format-time-string ignores user's preferred locale 2020-01-23 3:48 bug#39248: format-time-string ignores user's preferred locale Paul W. Rankin @ 2020-01-23 5:56 ` Eli Zaretskii 2020-01-23 6:44 ` Paul W. Rankin 2020-01-23 8:38 ` Paul Eggert 1 sibling, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2020-01-23 5:56 UTC (permalink / raw) To: 39248, hello On January 23, 2020 5:48:16 AM GMT+02:00, "Paul W. Rankin" <hello@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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#39248: format-time-string ignores user's preferred locale 2020-01-23 5:56 ` Eli Zaretskii @ 2020-01-23 6:44 ` Paul W. Rankin 2020-01-23 14:19 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Paul W. Rankin @ 2020-01-23 6:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 39248 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... ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#39248: format-time-string ignores user's preferred locale 2020-01-23 6:44 ` Paul W. Rankin @ 2020-01-23 14:19 ` Eli Zaretskii 0 siblings, 0 replies; 16+ messages in thread From: Eli Zaretskii @ 2020-01-23 14:19 UTC (permalink / raw) To: Paul W. Rankin; +Cc: 39248 > From: "Paul W. Rankin" <hello@paulwrankin.com> > Cc: bug-gnu-emacs@gnu.org, 39248@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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#39248: format-time-string ignores user's preferred locale 2020-01-23 3:48 bug#39248: format-time-string ignores user's preferred locale Paul W. Rankin 2020-01-23 5:56 ` Eli Zaretskii @ 2020-01-23 8:38 ` Paul Eggert 2020-01-23 13:12 ` Paul W. Rankin 1 sibling, 1 reply; 16+ messages in thread From: Paul Eggert @ 2020-01-23 8:38 UTC (permalink / raw) To: Paul W. Rankin; +Cc: 39248 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#39248: format-time-string ignores user's preferred locale 2020-01-23 8:38 ` Paul Eggert @ 2020-01-23 13:12 ` Paul W. Rankin 2020-01-23 18:05 ` Eli Zaretskii 0 siblings, 1 reply; 16+ messages in thread From: Paul W. Rankin @ 2020-01-23 13:12 UTC (permalink / raw) To: Paul Eggert; +Cc: 39248 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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#39248: format-time-string ignores user's preferred locale 2020-01-23 13:12 ` Paul W. Rankin @ 2020-01-23 18:05 ` Eli Zaretskii 2020-01-23 22:04 ` Glenn Morris 0 siblings, 1 reply; 16+ messages in thread From: Eli Zaretskii @ 2020-01-23 18:05 UTC (permalink / raw) To: Paul W. Rankin; +Cc: 39248, eggert > From: Paul W. Rankin <hello@paulwrankin.com> > Date: Thu, 23 Jan 2020 23:12:39 +1000 > Cc: 39248@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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#39248: format-time-string ignores user's preferred locale 2020-01-23 18:05 ` Eli Zaretskii @ 2020-01-23 22:04 ` Glenn Morris 2020-01-24 3:17 ` Paul W. Rankin 0 siblings, 1 reply; 16+ messages in thread From: Glenn Morris @ 2020-01-23 22:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 39248, Paul W. Rankin, eggert 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#39248: format-time-string ignores user's preferred locale 2020-01-23 22:04 ` Glenn Morris @ 2020-01-24 3:17 ` Paul W. Rankin 2020-01-24 7:35 ` Paul Eggert 0 siblings, 1 reply; 16+ messages in thread From: Paul W. Rankin @ 2020-01-24 3:17 UTC (permalink / raw) To: Glenn Morris; +Cc: 39248, eggert > On 24 Jan 2020, at 8:04 am, Glenn Morris <rgm@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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#39248: format-time-string ignores user's preferred locale 2020-01-24 3:17 ` Paul W. Rankin @ 2020-01-24 7:35 ` Paul Eggert 2020-01-25 9:36 ` Paul W. Rankin 2020-01-25 11:18 ` Alan Third 0 siblings, 2 replies; 16+ messages in thread From: Paul Eggert @ 2020-01-24 7:35 UTC (permalink / raw) To: Paul W. Rankin, Glenn Morris; +Cc: 39248, Alan Third [-- Attachment #1: Type: text/plain, Size: 908 bytes --] 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@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. [-- Attachment #2: 0001-Propagate-NSLocale-into-Emacs-better.patch --] [-- Type: text/x-patch, Size: 1405 bytes --] From 82821adea730dab5a42d24e49675ade1c2f5c1f3 Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Thu, 23 Jan 2020 23:16:47 -0800 Subject: [PATCH] Propagate NSLocale into Emacs better * src/emacs.c (main): Call ns_init_locale before using the environment variable that ns_init_locale sets up (Bug#39248). --- src/emacs.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/src/emacs.c b/src/emacs.c index 4b5d00a0e8..c170333e60 100644 --- a/src/emacs.c +++ b/src/emacs.c @@ -1242,6 +1242,9 @@ main (int argc, char **argv) char *lc_all = getenv ("LC_ALL"); if (! (lc_all && strcmp (lc_all, "C") == 0)) { + #ifdef HAVE_NS + ns_init_locale (); + #endif setlocale (LC_ALL, ""); fixup_locale (); } @@ -1610,10 +1613,6 @@ main (int argc, char **argv) #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 if (!noninteractive) { @@ -1724,11 +1723,6 @@ main (int argc, char **argv) globals_of_gfilenotify (); #endif -#ifdef HAVE_NS - /* Initialize the locale from user defaults. */ - ns_init_locale (); -#endif - /* Initialize and GC-protect Vinitial_environment and Vprocess_environment before set_initial_environment fills them in. */ -- 2.24.1 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#39248: format-time-string ignores user's preferred locale 2020-01-24 7:35 ` Paul Eggert @ 2020-01-25 9:36 ` Paul W. Rankin 2020-01-25 11:18 ` Alan Third 1 sibling, 0 replies; 16+ messages in thread From: Paul W. Rankin @ 2020-01-25 9:36 UTC (permalink / raw) To: Paul Eggert; +Cc: Alan Third, 39248 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#39248: format-time-string ignores user's preferred locale 2020-01-24 7:35 ` Paul Eggert 2020-01-25 9:36 ` Paul W. Rankin @ 2020-01-25 11:18 ` Alan Third 2020-01-25 11:42 ` Paul W. Rankin 2020-01-26 8:35 ` Paul Eggert 1 sibling, 2 replies; 16+ messages in thread From: Alan Third @ 2020-01-25 11:18 UTC (permalink / raw) To: Paul Eggert; +Cc: Paul W. Rankin, 39248 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#39248: format-time-string ignores user's preferred locale 2020-01-25 11:18 ` Alan Third @ 2020-01-25 11:42 ` Paul W. Rankin 2020-01-25 12:03 ` Alan Third 2020-01-26 8:35 ` Paul Eggert 1 sibling, 1 reply; 16+ messages in thread From: Paul W. Rankin @ 2020-01-25 11:42 UTC (permalink / raw) To: Alan Third; +Cc: Paul Eggert, 39248 > On 25 Jan 2020, at 9:18 pm, Alan Third <alan@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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#39248: format-time-string ignores user's preferred locale 2020-01-25 11:42 ` Paul W. Rankin @ 2020-01-25 12:03 ` Alan Third 0 siblings, 0 replies; 16+ messages in thread From: Alan Third @ 2020-01-25 12:03 UTC (permalink / raw) To: Paul W. Rankin; +Cc: Paul Eggert, 39248 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@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#39248: format-time-string ignores user's preferred locale 2020-01-25 11:18 ` Alan Third 2020-01-25 11:42 ` Paul W. Rankin @ 2020-01-26 8:35 ` Paul Eggert 2020-01-26 10:26 ` Alan Third 1 sibling, 1 reply; 16+ messages in thread From: Paul Eggert @ 2020-01-26 8:35 UTC (permalink / raw) To: Alan Third; +Cc: Paul W. Rankin, 39248-done 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#39248: format-time-string ignores user's preferred locale 2020-01-26 8:35 ` Paul Eggert @ 2020-01-26 10:26 ` Alan Third 0 siblings, 0 replies; 16+ messages in thread From: Alan Third @ 2020-01-26 10:26 UTC (permalink / raw) To: Paul Eggert; +Cc: Paul W. Rankin, 39248-done 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-01-26 10:26 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-01-23 3:48 bug#39248: format-time-string ignores user's preferred locale Paul W. Rankin 2020-01-23 5:56 ` Eli Zaretskii 2020-01-23 6:44 ` Paul W. Rankin 2020-01-23 14:19 ` Eli Zaretskii 2020-01-23 8:38 ` Paul Eggert 2020-01-23 13:12 ` Paul W. Rankin 2020-01-23 18:05 ` Eli Zaretskii 2020-01-23 22:04 ` Glenn Morris 2020-01-24 3:17 ` Paul W. Rankin 2020-01-24 7:35 ` Paul Eggert 2020-01-25 9:36 ` Paul W. Rankin 2020-01-25 11:18 ` Alan Third 2020-01-25 11:42 ` Paul W. Rankin 2020-01-25 12:03 ` Alan Third 2020-01-26 8:35 ` Paul Eggert 2020-01-26 10:26 ` Alan Third
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).