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