Open Bug 379279 Opened 18 years ago Updated 2 years ago

LANG environment setting overrides LC_TIME

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
UNCONFIRMED

People

(Reporter: bughunter2, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070221 Red Hat/1.5.0.10-0.1.el4 Firefox/1.5.0.10 Build Identifier: version 2.0.0.0 (20070326) In order to have my date format in YYYY-MM-DD, I set my LC_TIME environment setting to en_DK.UTF-8. However, this doesn't work if LC_LANG is set to C. Since LC_LANG is a more general environment variable, it should not override the more specific LC_TIME setting. I'd love to leave LC_LANG unset but some old applications require it to be left a "C". This results in the unpleasant (and ambiguous) M/D/Y default format. Please change the handling so that LC_TIME has precedence over LC_LANG. This problem is seen with both TB 2.0 and 1.5 Reproducible: Always Steps to Reproduce: 1. LANG=C LC_TIME=en_DK.UTF-8 thunderbird => broken date format 2. LANG= LC_TIME=en_DK.UTF-8 thunderbird => correct date format Actual Results: In the first example above, the date format appears as MM/DD/YY despite the fact that LC_TIME is set to en_DK. In the second case, when LC_ALL is empty (or unset), the date format adheres to the LC_TIME setting. Expected Results: As long as LC_TIME is set, the date format shouldn't be affected by any other settings.
1. I don't have the privs to do it, but the Summary should mention LANG, not LC_LANG (cf. Steps to Reproduce). 2. With $LANG set to POSIX (sic) and $LC_ALL unset, Tb2 obeys my LC_TIME=en_GB setting Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.7pre) Gecko/20070820 Thunderbird/2.0.0.7pre
Formating of date&time seems to be executed in next modules(FormatTMTime). (See Bug 360018 Comment #21) >http://lxr.mozilla.org/seamonkey/source/intl/locale/src/windows/nsDateTimeFormatWin.cpp#125 >http://lxr.mozilla.org/seamonkey/source/intl/locale/src/unix/nsDateTimeFormatUnix.cpp#180 >http://lxr.mozilla.org/seamonkey/source/intl/locale/src/mac/nsDateTimeFormatMac.cpp#338 And locale checking etc. seems to be done before above call(in ::Initialize). > http://lxr.mozilla.org/seamonkey/source/intl/locale/src/unix/nsDateTimeFormatUnix.cpp#55 (If check failed, defaults to en-US ) ( > 80 mPlatformLocale.Assign("en_US"); ) Can logic in nsDateTimeFormatUnix::Initialize have relation to this bug's problem?
Assignee: mscott → nobody
Editing Summary according to my comment #1 item 1 (I got the privs in the meantime :-) ).
Summary: LC_LANG environment setting overrides LC_TIME → LANG environment setting overrides LC_TIME
Version: unspecified → 2.0
I cannot reproduce this in the TB nightly builds, following the STR per comment #0 My results: 1. LANG=C LC_TIME=en_DK.UTF-8 thunderbird => Date format: YYYY-MM-DD HH:mm 2. LANG= LC_TIME=en_DK.UTF-8 thunderbird => Date format: YYYY-MM-DD HH:mm My default language setting (en_US) provides the date format: MM/DD/YYYY hh:mm AM|PM
FYI I have attempted to reproduce a similar issue and cannot reproduce. (thunderbird 8 via Ubuntu 11.10) 1) LC_ALL= LANG=C LC_TIME=en_GB.utf8 thunderbird => Date Format as per en_GB.utf8 2) LC_ALL= LANG= LC_TIME=en_GB.utf8 thunderbird => Date Format as per en_GB.utf8
Reporter: Is this still a problem ?
Comment #0 and the original formulation of the Summary seems to confuse LC_ALL (which should override LC_TIME and all other LC_something settings) and LANG (which only provides a fallback value for the LC_something settings which are unset or empty). If the reporter meant that LC_ALL overrides LC_TIME, this is intentional; in this case the bug is INVALID. If he really meant LANG but the bug has disappeared, then the bug is WORKSFORME. It is only if LANG actually overrides LC_TIME that further action is required.
Hi there, On SeaMonkey-2.8, I see this 1) at login (LC_TIME set in .bashrc, all the rest from system): $ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME=en_DK.UTF-8 LC_COLLATE=C LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= => LC_TIME is *not* honored 2) in terminal (or via alias/wrapper script): $ export LANG=; seamonkey => LC_TIME is honored Also, it looks like that once LANG is set (empty or not) in a terminal, and seamonkey launched from there, then LC_TIME is honored... puzzling. Cheers, ^s
I think that your first example (when launching SeaMonkey by a desktop shortcut or by Alt+F2) bypasses the bashrc. For instance my ~/.basrc includes a line alias cls='clear' but when I launch gvim from a desktop shortcut, :!type -a cls answers /bin/bash: line 0: type: cls: not found shell returned 1 Your second example launches SeaMonkey from a shell prompt where LC_TIME is defined. You might try to set LC_TIME as part of whatever your desktop shortcut is running, or if necessary have it launch something like bash -c 'export LC_TIME=en_DK.UTF-8 ; seamonkey' or similar.
Yep, I just realized that most of my grief comes from KDE ignoring my login ENV -- fairly common in any X.org set up, I guess. But specifically with KDE, khotkeys seems to also ignore any ENV variable set in a wrapper script (see Bug <https://bugs.kde.org/show_bug.cgi?id=299107>). I confirm that any LANG/LC_TIME combination is honoured when running from the command line. So, as for SeaMonkey, I'd say this is WORKSFORME.

The LC_TIME workaround broke with SeaMonkey-2.53: dates in Mail and Calendar are formatted according to the chosen locale (Language preferences). I guess this happens because of Bug 1426907.

Current (when I say defined I mean fr_FR.UTF-8):

  • LC_TIME undefined, LC_ALL undefined, LANG undefined : Non-french dates, as expected.
  • LC_TIME undefined, LC_ALL undefined, LANG defined : Non-french dates
  • LC_TIME undefined, LC_ALL defined, LANG undefined : French dates \o/
  • LC_TIME undefined, LC_ALL defined, LANG defined : French dates
  • LC_TIME defined, LC_ALL undefined, LANG undefined : Non-french dates :,-(
  • LC_TIME defined, LC_ALL undefined, LANG defined : Non-french dates
  • LC_TIME defined, LC_ALL defined, LANG undefined : French dates
  • LC_TIME defined, LC_ALL defined, LANG defined : French dates

So it strangely looks like only LC_ALL has any impact on date format in Thunderbird.

(Tested on 68.12.0 (64-bit), on Debian bullseye)

Looks fixed in 78 (but a new settings has been added to choose between application locale or regional locale).

Update: I'm now on Thunderbird 78.4.1 (the version with the "Date and Time Formatting" in Preferences).

I tried various combinations of LC_ALL, LC_TIME, with C, en_DK.UTF-8, fr_FR.UTF-8, en_US.UTF-8, but were unable to obtain ISO 8601 format, YYYY-MM-DD.

A step to enhance this would be to show an example of formatted date in the "Date and Time Formatting" section of preferences screen, and maybe to add a picker containing more choices than "Application locale" and "Regional settings locale"

I look forward to testing v78 but am unable to do so with my current Ubuntu 18.04 setup. I am told that I will be able to move to 20.04 by the end of the year.

Julien, thank you for your help. It appears that at least part of my problem is that the date format for en_DK has changed somewhere along the line! This means that my testing was misleading. Strangely enough, so has en_CA. So if I use LC_ALL= LANG=C LC_TIME=en_CA.utf8 thunderbird, I get the desired behaviour with dates in YYYY-MM-DD format. Unfortunately, time is still shown in 12-hour am/pm format. Jason's examples and my examples from 11 years ago do not have the same behaviour today.

My deepest apologies to Mattias who asked 9 years ago "Reporter: Is this still a problem ?" The (very late) answer is that it appears to have been fixed but I can't tell you when the behaviour changed.

When I am able to test v78, I will post an update.

Regarding the Tony's comment:

If the reporter meant that LC_ALL overrides LC_TIME, this is intentional; in this case the bug is INVALID.

I have a hard time accepting that this is correct behaviour. The general should not override the specific; it should be the other way around. I can't think of a scenario where Tony's intentional behaviour is desirable.

LC_ALL= LANG=C LC_TIME=en_CA.utf8 thunderbird

In 78.4.1 too, this gives the "2020-11-09, 7:33 p.m." format too. So I have to find a LC_TIME that fits my brain.

Tried again some combinations, found:

LC_ALL= LANG=C LC_TIME=swedish thunderbird

which gives what I'm searching for: YYYY-MM-DD HH:MM.

If I set LC_ALL, LC_ALL wins, so it have to be unset or empty. But I can change LANG.

So:

LC_ALL= LC_TIME=swedish thunderbird

works for me (my LANG is en_US.UTF-8), but should LC_TIME win over LC_ALL?

Subtlty: If LC_ALL is unset, LC_TIME is not considered, but if LC_ALL is set but empty, LC_TIME is used. (stil on Thunderbird 78.4.1).

I'm on Thunderbird 78.5. I've tried various combinations of LC_ALL/LC_TIME/LANG but only LC_ALL seems to have any effect for me.

Interestingly, if LC_ALL is empty the options under "Date and Time Formatting" don't show any text.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.