238109 - (DateTimeKDE) KDE settings for Date and Time shall be honoured

Status: RESOLVED FIXED

(Core :: Internationalization, enhancement)

Description

[Constantine A. Murenin]

KDE has certain settings for Date and Time format. Mozilla needs to honour those
in FormatTime methods.

Comment 1

[Constantine A. Murenin]

*** Bug 238094 has been marked as a duplicate of this bug. ***

Comment 2

[Felix Miata]

*** This bug has been marked as a duplicate of 238094 ***

*** This bug has been marked as a duplicate of 238094 ***

Comment 3

[R.K.Aa.]

Is this filed as a chatzilla bug? I would rather think *KDE* should honor the OS
settings - on *nix at least (don't know if they make KDE for other OS'es.)

echo $LC_TIME
Mozilla - at least mailnews - already honors the $LC_TIME locale.

(And if this really is a general Mozilla bug, as reporter indicates, it should
probably at least be made blocker of bug 140751 - like bug 203367)

Reporter: Where is it you see the erronous time formats?

Comment 4

[Constantine A. Murenin]

(In reply to comment #3)
> Is this filed as a chatzilla bug? 

No, of cause not. 

> probably at least be made blocker of bug 140751 - like bug 203367)

Done. 

Comment 5

[Felix Miata]

SuSE 8.2
#set | grep LANG
RC_LANG=en_US

In KDE Control Center, time format is set to 24 hour.

In vc1, 'date +"%x %X"' returns the desired:
03/20/04 15:53:38
and 'date +"%c --- %x %X"' returns the desired:
Sat Mar 20 15:54:35 2004 --- 03/20/04 15:54:35

However in KDE console,  'date +"%x %X"' returns:
03/20/04 03:57:14 PM
and 'date +"%c --- %x %X"' returns:
Sat 20 Mar 2004 03:58:37 PM EST --- 03/20/04 03:58:37 PM

Mozilla reports the time in AM/PM format instead of the 24 hour format set in KDE.

Comment 6

[R.K.Aa.]

this is not a major bug - locales are honored. IMO it should be an RFE, but
lowering severity to normal for now.

Comment 7

[Constantine A. Murenin]

Please ignore comments 1--6; they have nothing to do with this bug. 

jshin: 
is it possible to create nsDateTimeFormatKDE.cpp and link it with
nsDateTimeFormatUnix.cpp? Or do we need to make changes in
nsDateTimeFormatUnix.cpp? How will this work practically? 

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #7)
> is it possible to create nsDateTimeFormatKDE.cpp and link it with
> nsDateTimeFormatUnix.cpp? Or do we need to make changes in
> nsDateTimeFormatUnix.cpp? How will this work practically? 

whatever you do, do _not_ introduce a dependency on kdelibs. (except via
dlopen() or somesuch, of course)

Comment 9

[Jungshik Shin]

I don't think this bug should be fixed in an ad-hoc manner like you suggested.
(although it can be done that way). If we want to fix it, we have to do the
'right' way, which means it's gonna take very long and that it can't be done by
mozilla alone. We need a sort of generic (as opposed to desktop specific)
'locale information' exchange protocol/framework (currently all we have now is
LC_TIME, but that's too coarse-grained and depending on setlocale() in general
is not such a good idea, which is why we have this and other similar bugs). In
that light, we may have to reverse the dependency between this and bug 238094. 

Comment 10

[Tristan Miller]

Is there any workaround for this, other than setting LC_TIME by trial and error until it happens to match the formats set in the KDE System Settings?  (I want my time formatted as HH:MM, my short date as YYYY-MM-DD, etc., but damned if I know which locale, if any, happens to correspond to my particular combination of format preferences.)  Is there a human-readable list of locales and their time/date formats, or some easy way of creating a new locale with given time/date formats?

Comment 11

[Zibi Braniecki [:zbraniecki][:gandalf]]

Tristan - we've reworked our language matching in Gecko over the last months. We now do proper language negotiation and attempt to do smart matching between LC_TIME and Firefox languages.

By default, if the language portion of the locale tag (say, "en-US" and "en-GB") match, we'll take your LC_TIME when formatting date/time in Firefox.
If the language portion does not match (say, "en-US" and "it-IT"), we will use Firefox' locale. If you want to force Firefox to follow OS locale, there's a pref "intl.regional_prefs.use_os_locales". If you set it to true, we should follow.

Can you please verify it against Nightly on KDE?

Comment 12

[Tristan Miller]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #11)
> Tristan - we've reworked our language matching in Gecko over the last
> months. We now do proper language negotiation and attempt to do smart
> matching between LC_TIME and Firefox languages.
> 
> By default, if the language portion of the locale tag (say, "en-US" and
> "en-GB") match,

I'm sorry, I'm not sure I understand.  If the language portion of the locale tag matches *what*?  Are you referring to some language setting in Firefox?  If so, I'm not sure that's of any help to me, as I don't use Firefox.

> we'll take your LC_TIME when formatting date/time in Firefox.
> If the language portion does not match (say, "en-US" and "it-IT"), we will
> use Firefox' locale. If you want to force Firefox to follow OS locale,
> there's a pref "intl.regional_prefs.use_os_locales". If you set it to true,
> we should follow.
> 
> Can you please verify it against Nightly on KDE?

This whole bug may be moot now.  As of Plasma 5, it is no longer possible to fine-tune the system locale settings the way it was when this bug report was created.  (See <https://bugs.kde.org/show_bug.cgi?id=340982> for the ensuing wailing and gnashing of teeth.)  AFAIK manually setting LC_TIME has always (crudely) worked around this issue in SeaMonkey and Thunderbird.  If that workaround didn't work in Firefox until now, then that's news to me, but it probably has nothing to do with KDE.

Comment 13

[Zibi Braniecki [:zbraniecki][:gandalf]]

Sorry for the confusion Tristan.

> I'm sorry, I'm not sure I understand.  If the language portion of the locale tag matches *what*?

If the language portion of the Firefox/Thunderbird/Seamonkey Locale and Regional Preferences Locale in your KDE.

Which means, if you have you Gecko app in en-US, and set KDE Regional Preferences Locale (LC_TIME, or in KDE settings) to "en-GB", we should pick it up in the recent Nightly and use regional settings (date/time/number formats etc.) from GB, rather than US.

> AFAIK manually setting LC_TIME has always (crudely) worked around this issue in SeaMonkey and Thunderbird.

That should work better now, hence my request :)

If you think that this bug is not relevant anymore and Gecko apps interact with KDE Regional Prefs settings properly, I'd be inclined to close this it.

Comment 14

[Tristan Miller]

This bug is no longer relevant for Firefox and SeaMonkey on KDE, for a couple reasons. First, KDE no longer allows for fine-grained customization of the date and time format; you must select from a predefined locale. Making such a selection in the KDE system settings dialog is essentially the same thing as setting LC_TIME, etc. in your environment. Second, Firefox and SeaMonkey correctly format the date and time according to this locale.

Recent versions of Thunderbird do have problems with formatting dates and times according to the user's selected locale; this is the subject of Bug 1426907. I suggest that this bug be closed as a duplicate of Bug 1426907.

Comment 15

[Axel Hecht [:Pike]]

Thanks Tristan.

I'll just resolve this FIXED, as we made some change in toolkit and/or KDE that actually fixed this.

W/out stepping too deep into bug 1426907, I haven't seen anybody testing TB 68, which is the latest stable release. It might be that they're not updating 60 users to 68, https://wiki.mozilla.org/Thunderbird:Home#Releases says "sometime in September". But it's worth testing.

Comment 16

[Tristan Miller]

Thanks for your comments, Axel.

Unfortunately, Thunderbird 68 has the same problem as Thunderbird 60 when it comes to formatting dates; this is due to the introduction in Thunderbird 60 of a dependency on the Unicode Consortium's Common Locale Data Repository (CLDR). Without undoing this rather extensive change, the issue can probably only be fixed upstream: https://unicode-org.atlassian.net/browse/CLDR-12027 I see you're very active in localization issues, so if you happen to know any CLDR developers, it would be great if you could help attract their attention to that upstream issue.