On Sat 27 Dec 2025 at 12:31:57 (+0100), Nicolas George wrote: > David Wright (HE12025-12-24): > > > 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. > > Indeed. Me neither. > > > 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? > > Exactly. Just like it would print dates in French if the source computer > did. > > > 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. > > Obviously. It is an universal principle that, unless security is > involved, a user-settable setting should override a system-wide setting. > > > I can't see what function LC_TZ has except to sit between > > /etc/localtime and TZ in increasing order of priority. If you > > Of course, it should have been done like that from the start.
Fair enough. It wasn't, but now I understand what you might have lobbied for at some time in the past, whenever that was. > > tell ssh to pass your TZ setting, then TZ could do the job in > > the next paragraph, couldn't it? > > Not unless you also have the authority to tell sshd to accept the TZ > setting. > > A possible work-around would be to set $LC_TZ locally even though it has > no effect at all except being passed and accepted by default, and have > your init scripts on the remote computer set TZ from LC_TZ. > > > 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. > > Of course the opposite is reasonable. Fortunately, everything I describe > is entirely configurable by each user. You've clarified what you meant by introducing the concept of LC_TZ, thanks. > > 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? > > It does not matter whether you think it benefits you or not, because I > am telling you a fact: unless you use a distribution for advanced users > that asks questions 99% of people would not understand, you will have > them on your system anyway. I'm aware of that. You wrote "Nowadays, I would say most system have most standard locales installed": I interpreted "installed" as those chosen from the list and compiled, rather than all the list entries. OTOH installing tzdata installs everything, ready to use. That's the difference. > Furthermore, you also have hundreds of mega-octets of > /usr/share/locale/*/LC_MESSAGES, translations in foreign languages you > do not speak and no manner of `dpkg-reconfigure locales` will get you > rid of. Sure, about 350MB when I last looked, around 5 years ago. I've seen some people on this list who would prefer to prune them. > > 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. > > Indeed, but what you describe is a job for a tool for easy system > configuration: tell it the country, and it will fill-in the various > settings. > > The braindead thing is to have to use the name of a country to designate > the paper size instead of the name of the paper size itself. It might help those not knowing the name of the "normal" papersize for a particular country. It can make the scheme more extensible: keywords could be added for, say, envelope or book sizes that vary territorially. Using the paper name itself could lead to ambiguities when the same name is used in some countries for paper of a different size. > > 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. > > Only if you have write access to system directories. > > > If it isn't offered by the debian-installer, it's certainly available > > in the dpkg-reconfigure locales list. > > Once again, you are completely missing the point: what does Denmark have > to do with ISO dates? Why should an English speaker living anywhere in > the world have to pretend to live in Denmark just to get date in ISO > format? If that bugs you, again, you might write a variant so you can have both fr_FR@mypaper and fr_FR@isotimedate, or whatever. > > It could indeed, which would mean lightdm's creators introduced a > > third selection to potentially contradict the other two. > > Not a “third” selection, a *stateful* selection. Stateful system state > is one of the worst fake-good ideas of computing. From the OP's description I got the impression the keyboard layout was configured rather than stateful. AIUI, stateful is where it remembers a /user's/ previous selection (like too often happens with printer queues). Here, I don't think the OP was able to make a selection as a user, but had to have write access to system directories. (Since Max's comment was posted, there seems to be some ambiguity about whether the keyboard layout can be changed by a user with the lightdm-gtk-greeter package.) Cheers, David.
