What sets LC_TIME?

[Anssi Saari]

With the recent LC_ALL thread, I noticed I have LC_TIME set by
mysterious means on at least two headless systems, for example:

$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE=en_US.utf8
LC_NUMERIC=en_US.utf8
LC_TIME=en_DK.utf8
LC_COLLATE=en_US.utf8
LC_MONETARY=en_US.utf8
LC_MESSAGES=en_US.utf8
LC_PAPER=en_US.utf8
LC_NAME=en_US.utf8
LC_ADDRESS=en_US.utf8
LC_TELEPHONE=en_US.utf8
LC_MEASUREMENT=en_US.utf8
LC_IDENTIFICATION=en_US.utf8
LC_ALL=

LC_TIME ends up with en_DK.utf8. It's what I usually want so I've
probably set this up and possibly I did it in the Debian installer but
where does it come from? /etc/default/locale has just LANG=en_US.UTF-8

find /etc /home/as -type f -print0 -follow|xargs -0 grep -e LC_TIME -e en_DK

does find some matches, in /etc/locale.gen as expected and in some
binary files but not in any relevant config file. Come to think of it,
is this actually hidden inside the initrd somehow?

[Greg Wooledge]

On Fri, Feb 16, 2024 at 10:24:07AM +0200, Anssi Saari wrote:
> With the recent LC_ALL thread, I noticed I have LC_TIME set by
> mysterious means on at least two headless systems, for example:
>
> $ locale
> LANG=en_US.UTF-8
> LANGUAGE=
> LC_CTYPE=en_US.utf8
> LC_NUMERIC=en_US.utf8
> LC_TIME=en_DK.utf8
> LC_COLLATE=en_US.utf8
> LC_MONETARY=en_US.utf8
> LC_MESSAGES=en_US.utf8
> LC_PAPER=en_US.utf8
> LC_NAME=en_US.utf8
> LC_ADDRESS=en_US.utf8
> LC_TELEPHONE=en_US.utf8
> LC_MEASUREMENT=en_US.utf8
> LC_IDENTIFICATION=en_US.utf8
> LC_ALL=

This is *extremely* abnormal locale output. Here's mine:

unicorn:~$ locale
LANG=en_US.utf8
LANGUAGE=
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME=C
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

Do you see what's different? The double quotes are meaningful here.
A value that's printed in double quotes is not actually set -- it's
deduced from LANG. In my output, the only values that are actually
set are LANG and LC_TIME.

In yours, *every* variable is set (except LANGUAGE and LC_ALL).

> LC_TIME ends up with en_DK.utf8. It's what I usually want so I've
> probably set this up and possibly I did it in the Debian installer but
> where does it come from? /etc/default/locale has just LANG=en_US.UTF-8
>
> find /etc /home/as -type f -print0 -follow|xargs -0 grep -e LC_TIME -e en_DK
>
> does find some matches, in /etc/locale.gen as expected and in some
> binary files but not in any relevant config file. Come to think of it,
> is this actually hidden inside the initrd somehow?

I can't imagine how the initrd would be related.

My first suspicion would be your desktop environment, if you're running
one. Who knows what those things do.

If you login on a text console (Ctrl-Alt-F2 for example), do you still
get these same locale values? How about "ssh localhost" (if an ssh
server is installed)? If those differ from what you see in your desktop
environment, then it's a strong indicator the DE is doing something.

[Anssi Saari]

Greg Wooledge <gr...@wooledge.org> writes:

> On Fri, Feb 16, 2024 at 10:24:07AM +0200, Anssi Saari wrote:
>> With the recent LC_ALL thread, I noticed I have LC_TIME set by
>> mysterious means on at least two headless systems, for example:
>>
>> $ locale
>> LANG=en_US.UTF-8
>> LANGUAGE=
>> LC_CTYPE=en_US.utf8
>> LC_NUMERIC=en_US.utf8
>> LC_TIME=en_DK.utf8
>> LC_COLLATE=en_US.utf8
>> LC_MONETARY=en_US.utf8
>> LC_MESSAGES=en_US.utf8
>> LC_PAPER=en_US.utf8
>> LC_NAME=en_US.utf8
>> LC_ADDRESS=en_US.utf8
>> LC_TELEPHONE=en_US.utf8
>> LC_MEASUREMENT=en_US.utf8
>> LC_IDENTIFICATION=en_US.utf8
>> LC_ALL=
>
> This is *extremely* abnormal locale output. Here's mine:

Yah. It was ssh passing through all that. On serial console, locale
settings are as expected:

$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

[Greg Wooledge]

On Fri, Feb 16, 2024 at 03:34:12PM +0200, Anssi Saari wrote:
> Yah. It was ssh passing through all that. On serial console, locale
> settings are as expected:
>
> $ locale
> LANG=en_US.UTF-8
> LANGUAGE=en_US:en
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"

[...]

Well then, that just changes the mystery from "happens on the Debian
system I ssh into" to "happens on my ssh client". For some reason,
your ssh client has all of those LC_* variables set in its environment,
which is still quite unusual.

[David Wright]

Could something weird here do that?

$ grep LC /etc/ssh/*g
/etc/ssh/ssh_config: SendEnv LANG LC_*
/etc/ssh/sshd_config:AcceptEnv LANG LC_*
$

Perhaps the OP's also sets SetEnv … in the client's config?

Cheers,
David.

[Greg Wooledge]

That's all normal and expected.

What's odd is that client *actually has* LC_NUMERIC and so on set in
its environment. Which... is not a problem if they're all set to the
correct values. It's weird, but not wrong. The problem for the OP was
that one of the values was not set correctly, or at least not as
expected.

At this point we have no idea whether the ssh client is even a Unix/Linux
system. It could be anything. It could be a literal toaster.

[David Wright]

On Fri 16 Feb 2024 at 16:25:05 (-0500), Greg Wooledge wrote:
> On Fri, Feb 16, 2024 at 11:11:09AM -0600, David Wright wrote:
> > On Fri 16 Feb 2024 at 09:12:24 (-0500), Greg Wooledge wrote:
> > > On Fri, Feb 16, 2024 at 03:34:12PM +0200, Anssi Saari wrote:
> > > > Yah. It was ssh passing through all that. On serial console, locale
> > > > settings are as expected:
> > > >
> > > > $ locale
> > > > LANG=en_US.UTF-8
> > > > LANGUAGE=en_US:en
> > > > LC_CTYPE="en_US.UTF-8"
> > > > LC_NUMERIC="en_US.UTF-8"
> > > > LC_TIME="en_US.UTF-8"
> > > [...]
> > >
> > > Well then, that just changes the mystery from "happens on the Debian
> > > system I ssh into" to "happens on my ssh client". For some reason,
> > > your ssh client has all of those LC_* variables set in its environment,
> > > which is still quite unusual.
> >
> > Could something weird here do that?
> >
> > $ grep LC /etc/ssh/*g
> > /etc/ssh/ssh_config: SendEnv LANG LC_*
> > /etc/ssh/sshd_config:AcceptEnv LANG LC_*
> > $
>
> That's all normal and expected.

Yes, they're off my system :) though I should have added -r to
catch any ssh_config.d/* files, as in the illustration below.

> What's odd is that client *actually has* LC_NUMERIC and so on set in
> its environment. Which... is not a problem if they're all set to the
> correct values. It's weird, but not wrong. The problem for the OP was
> that one of the values was not set correctly, or at least not as
> expected.

That's why I posted the last line about SetEnv, illustrated by:

$ cat /etc/ssh/ssh_config.d/test.conf
Host ahost
SetEnv LC_PAPER=en_GB.utf8
#
$ ssh ahost
Linux ahost 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64

The programs included with the Debian GNU/Linux system are free software;
[ … ]
You have new mail.
Last login: Fri Feb 16 22:41:18 2024 from 192.168.1.14
$ locale
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE=en_GB.UTF-8
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER=en_GB.utf8 ←
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=
$

It's not a place I'd have immediately thought of looking.

> At this point we have no idea whether the ssh client is even a Unix/Linux
> system. It could be anything. It could be a literal toaster.

More likely an æbleskiver pan?

Cheers,
David.

[to...@tuxteam.de]

On Fri, Feb 16, 2024 at 05:19:10PM -0600, David Wright wrote:
> On Fri 16 Feb 2024 at 16:25:05 (-0500), Greg Wooledge wrote:

[...]

> > At this point we have no idea whether the ssh client is even a Unix/Linux
> > system. It could be anything. It could be a literal toaster.
>
> More likely an æbleskiver pan?

But we know that all toasters run Unix, since a well-known company
got burnt by that recall they had to do.

On pans... I'm out of my depth, sorry.

;-)

Cheers
--
t

[Anssi Saari]

Not at all, I know perfectly well where that comes from. I'd be upset if
I didn't. I set all that in my shell config. It's a kind of a legacy
contamination from remote shell machines. As I don't have root on all
the shell machines I use, I have traditionally configured locales in
shell init there. And at some point, I've copied those locale settings
to my home desktop, possibly other machines too.

I guess one of these days I'll run update-locale and clean up my shell
config.

[debia...@howorth.org.uk]

Greg Wooledge <gr...@wooledge.org> wrote:

> That's all normal and expected.
>
> What's odd is that client *actually has* LC_NUMERIC and so on set in
> its environment. Which... is not a problem if they're all set to the
> correct values. It's weird, but not wrong. The problem for the OP
> was that one of the values was not set correctly, or at least not as
> expected.

It's not weird at all. It's how many people set their machines, when
they have logical minds and prefer YYYY-MM-DD date format rather than
the illogical messes most countries have in their locales.

[Greg Wooledge]

It's weird to set *every* LC_* variable when all you want to change is
LC_TIME.

I personally set LANG and LC_TIME. But I don't set the others. Why
would I? That would be weird.

unicorn:~$ locale
LANG=en_US.utf8
LANGUAGE=
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME=C
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

As you can see, the only variables with unquoted, non-empty values are
LANG and LC_TIME.