Greg Wooledge (HE12025-12-24): > 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.
Of course. But we are still allowed to say that the people who designed and standardized this did a very bad job. > 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. It is a wording that caters for ignorant click-everywhere system administrators who have not even bothered to learn what an environment variable is. > 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). Exactly. > 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. I will do it on the computers I administrate — we have quite a few users from over the world — and then maybe try. Regards, -- Nicolas George
