On Wed, Dec 24, 2025 at 00:06:35 -0600, David Wright wrote:
> $TZ overrides the time zone set by whatever /etc/localtime links to. If
> there were a "system setting" of LC_TZ, $TZ would override that too.
Having two different environment variables that both do the same job
is not a good design. At this point, it's *much* too late to rename
TZ to LC_TIMEZONE or whatever. That ship has sailed.
> By "system setting", which you wish me to call "system's default value",
> I mean what man 5 locale.conf is referring to here:
>
> "The /etc/locale.conf file configures system-wide locale settings."
You've omitted the most important part of that page, which is the sentence
immediately following that one:
DESCRIPTION
The /etc/locale.conf file configures system-wide locale settings. It is
read at early boot by systemd(1).
Given that information, we can easily verify what it's doing:
===============================================================
hobbit:~$ cat /etc/locale.conf
# File generated by update-locale
LANG=en_US.UTF-8
hobbit:~$ ps -fp 519
UID PID PPID C STIME TTY TIME CMD
root 519 1 0 Nov16 ? 00:00:05 /usr/lib/systemd/systemd-ude
hobbit:~$ sudo sh -c 'tr \\0 \\n < /proc/519/environ' | grep -e LANG -e LC
[sudo] password for greg:
LANG=en_US.UTF-8
===============================================================
It's sticking LANG (and/or LC_*) into the environment of each process
spawned by systemd. Or at least, the system-wide systemd service.
I'm not sure whether it also applies to the --user instances.
> "The locale settings configured in /etc/locale.conf are system-wide
> and are inherited by every service or user, unless overridden or
> unset by individual programs or users."
I'm not a huge fan of that wording. They should just say what actually
happens: the locale settings become environment variables, which are
naturally inherited by every spawned process. When they say "every
service or user", does that mean it also applies to --user instances
of systemd? Maybe. I can't be sure, though.
> I can't see what function LC_TZ has except to sit between
> /etc/localtime and TZ in increasing order of priority.
Yeah, that's not going to happen. Getting the POSIX committee to agree
to adding a new LC_ variable at this point, especially one that's
redundant? Nope.
> If you
> tell ssh to pass your TZ setting, then TZ could do the job in
> the next paragraph, couldn't it?
Except for the inconvenient fact that most people don't set TZ. And
most people don't change the sshd_config settings to accept TZ, which
most OS distributions don't add either. And therefore most people don't
try to pass TZ as a variable through ssh (since it wouldn't be accepted).
But in a hypothetical setup where
A) The user sets TZ on the client.
B) The user configures ssh to pass TZ.
C) The server admin configures sshd_config to accept TZ.
yes, in that case, the user's remote session would have their time zone.
If you can convince the Debian teams to add TZ to the list of variables
sent and accepted by ssh/sshd out of the box, that would be an effective
push toward making this scenario a commonplace one. I honestly have no
idea how welcome such a suggestion would be.
