On Mon 22 Dec 2025 at 16:49:08 (-0000), Bigsy Bohr wrote: > On 2025-12-21, [email protected] <[email protected]> wrote: > > On Sun 21 Dec 2025 at 12:41:49 (+0100), Nicolas George wrote: > > > >> (1) SSH will do nothing of the sort. SSH will just carry to you the > >> output of the commands running on the remote computer. > > > > Right. But it sets environment if its config allows. Here's, for > > example from /etc/ssh/sshd_config, which, AFAIK is Debian default: > > > > # Allow client to pass locale environment variables > > AcceptEnv LANG LC_* > > > >> (2) The timezone is not part of the locales, although it should. > > > > Makes sense to me, yes.
So what would be the relationshp between the system's value of LC_TZ and /etc/localtime? I assume one would have to set the other at boot time, but what would be the role of LC_TZ after that? (Bearing in mind that we already have TZ available for overriding the default.) The Sydney example didn't help me understand much, because I don't know what the ssh default behaviour is, or what you would want it to be and why. Isn't it just a matter of what you set TZ to in the .profile for your Sydney account? (Assuming you don't want that system's default time zone.) One difference between the locale system and the time zone one is that most people (I suspect) compile just a few locales (C/US/GB in my case) that are relatively static, but the time zone system is essentially geographically complete, and constantly being updated. Would that complicate package maintenance? > I once had a problem with the lightdm greeter, a US locale, and a French > keyboard where when the computer would go into power-saving mode, and > I'd wake it up again to type my password into the greeter, it would > default to a QWERTY. > > Same for the console. Of course, this is of no help to anyone, but I > thought I'd mention it anyway. That sounds like the OP's problem, and its cause could be similar; conflicting settings in more than one location. > It seems to me that locales used to present some difficulties over here > (I guess before UTF-8 came along). I still receive emails from time to > time where the accented characters are all screwy. I don't really know > how they achieve this. I think it could arise from writing in, say, the older ISO-8859-1 charset, as many of us did, but an MUA assuming it was in the newfangled UTF-8. Or vice versa. But that wouldn't involve the keyboard layout at all. Cheers, David.
