325528 - default date format without locale

Status: NEW

(MailNews Core :: Internationalization, enhancement)

Description

[Wouter Van Hemel]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; rv:1.8) Gecko/20060110 Debian/1.5.dfsg-4 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.8) Gecko/20060110 Debian/1.5.dfsg-4 Firefox/1.5


The default 'C' locale returns an ambiguous date format. Since a lot of people don't set the locale on their system, this is not a particularly handy or democratic format; this while there is an international standard, a useful standard even, ISO 8601, which is slowly gaining acceptance.

It's a great opportunity for thunderbird to both improve the software itself as to help this standard by falling back to it in case no locale has been set by the end user or system integrator.

This is not a request to have configurable date formats. Locale is meant for that. But in the case of unset locale variables, thunderbird should pick an unambiguous and rather country-independent format that will appeal to all and not one that causes confusion in most of the world.

Also, note that there is no easy workaround because it's not trivial to set up different locale variables for a session.



Reproducible: Always

Steps to Reproduce:

Comment 1

[rsx11m]

For Linux, the locale settings are determined by the LANG, and specifically
for the date and time formats, the LC_TIME environment variables.
The respective details are kept encoded in /usr/lib/locale/ or alike.

At least for the Thunderbird 2.0 versions (and other 1.8-branch applications), this works as long as LANG/LC_TIME are correctly provided in the environment when started up. Thus, it appears to be the responsibility of the window or desktop manager (such as KDE or Gnome) to derive and provide those from the system settings. This issue is obviously not restricted to Thunderbird alone.

If the environment variables are missing, IMHO the default should be to assume the locale of the installed Thunderbird version (i.e., LANG=en_US.UTF-8 for the English/North-American builds).

Comment 2

[Magnus Melin [:mkmelin]]

I doubt assuming a locale would work (well) - the locale might very well not be set up by the system. Isn't that why there is the "C" locale?

Comment 3

[rsx11m]

It appears that in nsLocaleService, the default behavior for XP_UNIX is to assume "en-US" as locale rather than "C" if LANG is not set, unless this is somehow localized (also at the time already when this bug was filed):

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/intl/locale/src/nsLocaleService.cpp&rev=1.68#178

Assuming "C" is always available as a fallback, proposed testing order
1. value of LC_TIME (if variable set and locale information available);
2. value of LANG;
3. locale of application, if set up correctly in the system;
4. locale "C" as last resort.

This would still require the desktop manager to correctly provide the system information to have any impact on the displayed dates and times, of course.

Comment 4

[rsx11m]

> The default 'C' locale returns an ambiguous date format. Since a lot of people
> don't set the locale on their system, this is not a particularly handy or
> democratic format; this while there is an international standard, a useful
> standard even, ISO 8601, which is slowly gaining acceptance.

Add a test on the presence of the en_DK.UTF-8 locale settings between points
#3 and #4 of the list above to accommodate this. While I personally have no problems with the appearance of the "C" locale, I see the point to use an ISO standard as a better fallback, as long as it is set up ("C" would be #5 then).

Comment 5

[rsx11m]

Confirming as enhancement request. While the impact may be considered trivial, it seems to be preferable to have a default date/time format corresponding to the locale rather than hard-wire it to en_US. The "C" locale should be taken as the last resort if no other definition is found.

Moving to Internationalization.