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. > 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. > 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. 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. > 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. > 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? > 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. Regards, -- Nicolas George
