On Tue 23 Dec 2025 at 11:06:43 (+0100), Nicolas George wrote: > David Wright (HE12025-12-23): > > So what would be the relationshp between the system's value of LC_TZ > > and /etc/localtime? > > There is no such thing as “the system's value of” locale settings, > locale settings are entirely local to a process. > > As for what should the system's *default* value be, I suggest: exactly > the same thing as currently $TZ.
I don't think I have TZ set to anything. $ echo "$TZ" $ date Tue Dec 23 23:43:45 CST 2025 $ readlink /etc/localtime /usr/share/zoneinfo/America/Chicago $ TZ=Europe/London date Wed Dec 24 05:43:55 GMT 2025 $ TZ= date Wed Dec 24 05:43:59 Universal 2025 $ date Tue Dec 23 23:44:02 CST 2025 $ $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. 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." "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." $ man 5 locale.conf | grep default $ So I think we agree on /what/ we're referring to. > > (Bearing in mind > > that we already have TZ available for overriding the default.) > > Indeed. And that makes it very easy to imagine how that environment > variable should have a slightly different name so as to be transmitted > automatically like the rest of the locale settings. > > > 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. > > ssh's default behaviour is this: > > sshd: AcceptEnv LANG LC_* > > ssh: SendEnv LANG LC_* COLORTERM NO_COLOR > > Nothing more. So if you login to Sydney from, say, Paris, where your LC_TZ might be set to Europe/Paris, the session in Sydney would still yield LC_TZ=Europe/Paris in response to the locale command, rather than LC_TZ=Australia/Sydney? Presumably to have any effect (and a reason to exist), it would have to override the Sydney system's setting of /etc/localtime (linked to Australia/Sydney) when you type the command date. > > 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.) > > Whether you set it globally for the system or in a personal config file > is the same: you get a setting that only depends on the remote computer > in Sydney. I can't see what function LC_TZ has except to sit between /etc/localtime and TZ in increasing order of priority. If you tell ssh to pass your TZ setting, then TZ could do the job in the next paragraph, couldn't it? > Remember that ssh lets you log in from all over the world. It is very > reasonable to want all your ssh sessions to many computers in the world > and your local session to talk to you in the same time zone. Entirely reasonable, though one can come up with reasons for the opposite view, like say, knowing whether the large number of local users on the Sydney machine are likely to be at work/sleeping/ quaffing Foster's. > > 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? > > Nowadays, I would say most system have most standard locales installed, > but that is a detail. On servers, perhaps, but I'm not sure what I, and many others, would use a locale like "Odia language locale for India" for, to take an example at random. What would be the benefit? > The issue you are mentioning is a instance of the broader that the way > locales are designed and implemented is completely braindead. > > Locale settings are lumped all together and summarized by a pair: a > language code and a country code. Since it was not enough, they added a > third field for the character encoding. > > Sure, for LC_MESSAGES it makes sense: “talk to me in French as spoken in > Canada”. > > But for other settings, it makes no sense at all. I mean, who is the > cretin who though a language code and a country code is the appropriate > way to designate a frigging paper format? Are you not allowed to speak > French, live in France and have your printer set up with 24×32 drawing > paper? I don't follow you here. Most countries have a standard paper size. It's quite convenient that a US locale chooses Letter, and a GB one A4. At work, we set up A3 printers through their printer queues: size was just one parameter; there were colour/BW, toner/inkjet/dye-sublimation, paper/foil selections as well. Even a system that was hooked up to an A0 printer would probably not want PDFs (for screen-reading or eventual printing) generated on the scale of an A0 sheet by default. But doesn't the locale system allow you to make a variant of your locale, just setting one or more parameters, and naming it, say, fr_FR@mypaper, so that LC_PAPER is customised for your printer. > Or do you want your dates in ISO format but still month names in English > when relevant? Well, you cannot, except if you know the workaround: > en_DK, “English as spoken in Denmark”. WTF?!? If it isn't offered by the debian-installer, it's certainly available in the dpkg-reconfigure locales list. > The need to “compile” locales stems from this absurdity and bad > implementation design on top of it. > > > That sounds like the OP's problem, and its cause could be similar; > > conflicting settings in more than one location. > > I am pretty sure the OP's problem is caused by lightdm having a built-in > keyboard selection mechanism to allow interactive change and remembering > the last setting. But I categorically refuse to use a crystal ball to > answer OPs's questions. It could indeed, which would mean lightdm's creators introduced a third selection to potentially contradict the other two. Cheers, David.
