System date and time formats are not respected (all platforms)

RESOLVED FIXED in Thunderbird 55.0

Status

RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: waltergr, Unassigned)

Tracking

54 Branch
Thunderbird 55.0
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507

Steps to reproduce:

1. Start Thunderbird.


Actual results:

The system date and time formats are not used in the display of dates and times, both in email views (such as folder listviews) and calendar views.


Expected results:

Display of dates and times throughout Thunderbird should use the system-wide display settings.
(Reporter)

Comment 1

2 years ago
I run TB nightlies.  The 2016-10-27 nightly *does* respect the date and time format settings.

The next nightly that I tried was 2017-01-14, and it doesn't respect those settings.  Nor does the 2017-03-04 nightly.

So it would seem that the bug was introduced after the revision used to generate the 2016-10-27 nightly, and before the revision used to generate the 2017-01-14 nightly.
Blocks: 1301640
TB will have to use OSPreferences to take system settings.
Depends on: 1308329
We would basically need something similar to what I'm doing in mozIntl in bug 1339650 (a blend of MozDateTimeFormat and OSPreferences).

Updated

2 years ago
Component: Untriaged → General

Comment 4

2 years ago
This has been discussed at length in bug 1325745, most recently in bug 1325745 comment #45 and further down.
I had a long discussion with Zibi in bug 1342753 comment #21 and further down.

The result is: All operating settings are ignored, if you want to see date/time format xx-YY, you need to use a localised version for that locale. Not even using an en-US version with a language pack for xx-YY currently works.

TB creates all its data/time displays via a C++ interface. I questioned Zibi about this C++ interface in connection with bug 1308329 which does pick up OS settings. The answer in bug 1342753 comment #33 was (quoting):

===
> What about bug 1308329? Does that re-introduce the ability to set the date/time
> format in the OS? Would that have an effect on dates/times formatted via the C++ interface?
Not automatically. I'm working on bug 1339650 that will introduce a JS API that merges DateTimeFormat and OSPreferences, but someone would have to improve the intl/locale/DateTimeFormat.cpp to also tap into OSPreferences to achieve the same on the C++ side.
===

So I read that to mean that two bugs need to be fixed before we can get C++ formatted times back:
Bug 1339650 and some other bug "to improve the intl/locale/DateTimeFormat.cpp to also tap into OSPreferences".

(In reply to Masatoshi Kimura [:emk] from comment #2)
> TB will have to use OSPreferences to take system settings.
How? Do you know more than I do (I'm sure you do) ;-)
Flags: needinfo?(VYV03354)
Isn't bug 1339650 about JS API? Why does it have to do with C++ API?

(In reply to Jorg K (GMT+1) from comment #4)
> > TB will have to use OSPreferences to take system settings.
> How? Do you know more than I do (I'm sure you do) ;-)

By migrating TB to JS API? DateTimeFormat will be eventually removed, I guess.
Flags: needinfo?(VYV03354)

Comment 6

2 years ago
(In reply to Masatoshi Kimura [:emk] from comment #5)
> By migrating TB to JS API? DateTimeFormat will be eventually removed, I
> guess.
That may be an option. Currently TB relies heavily on the C++ interface as we can see here:
https://hg.mozilla.org/comm-central/rev/2231f130a183eae79746df4da367062d0ad04a9d

As you know, DateTimeFormat::FormatPRTime() had its 'locale' parameter removed in bug 1301640, so now there is no way to set the locale we want to use for display. We have to rely on the locale retrieved internally and that has just changed from the "system" to the "browser/build" locate in bug 1342753. And as discussed there, that doesn't really suit the TB use case.

Updated

2 years ago
Duplicate of this bug: 1346190

Updated

2 years ago
OS: Unspecified → All
Hardware: Unspecified → All
Summary: System date and time formats are not respected on Windows → System date and time formats are not respected (all platforms) from TB 54 and later
Version: Trunk → 54 Branch

Comment 8

2 years ago
REPRODUCIBLE with unzipped installer of  official  en-US SeaMonkey 2.52a1 (NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0 Build 20170311002651  (Default Classic Theme) on German WIN7 64bit.

a) Was ok for me until Installation of SeaMonkey 2.51a1 Build 20170207004355
b) I wonder whether it might make a difference whether SM is installed or only
   unzipped?
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 9

2 years ago
For Bug 1335897 comment #7 Email date / time:

current behavior  SM 2.52a2: 3/5/17, 6:05 PM +0000
expected behavior SM 2.51a2: 05.03.17, 19:05 +0000 (because of German WIN7)

Comment 10

2 years ago
It is well understood why this happens:
https://hg.mozilla.org/mozilla-central/rev/439f5e4ed073#l1.37
from bug 1342753.

We need to wait until M-C finish bug 1339650. Eventually M-C must align the C++ produced times with the JS times, since C++ times are used in a few spots in FF (certificate details and the history (sidebar/library)).

Comment 11

2 years ago
Broken in Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 SeaMonkey/2.51a2
Build identifier: 20170312013001 3/14/17 5:01 PM

I hope this won't creep in stable version.

Updated

2 years ago
Duplicate of this bug: 1351903

Comment 13

2 years ago
Due to Comment 8 this seems to me a MaiNews Core Problem?!

Comment 14

2 years ago
No, it's a Core::Intl problem that's currently being fixed in bug 1351427. Sadly I lost a line in a refactoring exercise and the patch which had already landed on M-I got backed out.

Updated

2 years ago
Blocks: 1355565

Updated

2 years ago
Duplicate of this bug: 1355565

Comment 16

2 years ago
(In reply to  K Chayka comment #15)
And you are sure that a _Thunderbird_ fix will become integrated into SeaMonkey automatically?

Comment 17

2 years ago
It's a Mozilla Core::Intl fix. If that doesn't fix it, we're all hosed ;-)

Comment 18

2 years ago
Bug 1351427 has finally landed. That means the following:

The date/times in the Date/Received column which are formatted using C++ code in intl/locale/DateTimeFormat.cpp will now respect "language-matched" operating system set date and time formats.

What does "language-matched" mean? It means it will only respect OS setting for locales that match the language of the Thunderbird build.

Examples:
If you install an en-US Daily, you can set the locale to en-US, en-AU or en-GB and adjust the formats. If you set the locale to de-DE, those setting will be ignored.

The reason behind it is that the application should always look properly localised, so you cannot show German dates in an otherwise English application.

This is a decision Mozilla have taken, so please no discussion on that.

If you want to get German dates, use a localised version which is also available on all channels:
Daily, Aurora, Beta, Release.

===

Note that TB is also showing dates/times in other locations of the UI. They might not be consistent yet, we're still working on bug 1346549, bug 1313659 and bug 1356403.

Due to the complexity of Core::Intl changes, there won't be any uplift, so the situation is this:
TB 53: Uses the OS configured "format" locale but doesn't allow individual changes.
TB 54: Use the build locale for the application, no adjustment possible (yes, that's bad).
TB 55: Respects "language-matched" OS settings.
All version: Localised versions always show localised times.

===

Fixed by bug 1351427.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 55.0

Updated

2 years ago
No longer blocks: 1355565

Updated

2 years ago
Summary: System date and time formats are not respected (all platforms) from TB 54 and later → System date and time formats are not respected (all platforms) in TB 54
This should not be marked as "RESOLVED", though, but rather as "WON'T FIX", as the issue remains.

It should be clear that no other native app for the Mac behaves like that, even if it's not localized for the language the date locale uses.

That's why I had brought up this bug in the first place: Thunderbird does not adhere to the expectations and common behavior of regular Mac apps.

Also, "If you want to get German dates, use a localised version" is not a proper solution to this, it's a work-around at best: If I did this, I'd have an app in German language, which I do not want. I want an English speaking app that respects the system-wide set locale when formatting dates. That's what any "regular" Mac app does. Therefore, this issue is not really solved - it's been dropped.

I accept closing this issue (though I still shake my head about the decision made by Mozilla), but calling it resolved is not correct, IMO.
Sorry to add more. Maybe this solution using the properly localized app version is normal for Windows and Linux, though. When I reported the bug in the first place, it was reliated to OS X only. Maybe it's more appropriate to open a separate issue for OSX, where it's marked as "won't fix", then, whereas for Win and Linux it's resolved as that's common practise on those platforms. Just a thought. But as a developer, I don't like to see something that's clearly not right behavior being tagged as "fixed". But then, I'm not involved in this project as a developer, so maybe I just have to shut up now :)
Anyway, thanks for looking into this.

Comment 21

2 years ago
Will this respect the ISO-8601 format in the en_DK.utf8 locale when used with en builds of TB?

Comment 22

2 years ago
YYYY-MM-DD works on Windows since the various en-* locales offer that format. I can't speak for other platforms, but it should work.

As for the other discussion: I've been seeing this in various bugs, for example in bug 1354339 comment #63.
> It should be clear that no other native app for the Mac behaves like that, even if it's not localized for the language the date locale uses.

I believe that absolutely every app that allows users to select the UI locale does it.
The apps that don't will follow OS locales.

The problem we had in Fx/Tb/Sm is that we did a blend of both - we allowed users to select a locale (for example you can download Italian Thunderbird, but you can't download "Italian Safari"), but then, for historical reasons, took date/time formatting from the OS.

That of course caused tons of incompatibilities and limited us in getting date/time blended into localization.

> I want an English speaking app that respects the system-wide set locale when formatting dates. That's what any "regular" Mac app does. Therefore, this issue is not really solved - it's been dropped.

I do not believe you are right. Mac OS API for date/time formatting asks you to paste the locale for which you're formatting dates. 
Let's say you have en-US Thunderbird in German MacOS. If you paste en-US to Mac OS API for date/time formatting, you'll get en-US weekday/month names and en-US patterns customized to your regional preferences.
If you paste German, you'll get default german patterns (without your regional settings) and german translations of month and weekdays.

I believe that the use case you're describing ("I want English speaking app with German dates") is in direct contradiction to our goal of getting localization and internationalization synchronized.

In other words, we're aiming to be able to build a translation message "Today is Tuesday" where Tuesday is taken from DateTimeFormat and "Today is { $date }" is taken from localization.

In your use case, we'd end up with "Today is Dienstag" which is at best weird for any regular user, but may be potentially more dangerous. Let's say you get en-US Thunderbird on French OS and instead of Tuesday you get "dd/mm/yyyy".
That of course, in en-US will be "mm/dd/yyyy", but when resolved will look like "Today is 03/04/2017" - I hope you realize that this is very confusing to a user who doesn't know that we pick up translation from your app UI locale, but date from your OS locale.

And then there are even more problems when you start trying to get to Arabic OS and en-US Thunderbird  because now the dates are right-to-left and your translations and UI is left-to-right. Good luck resolving that.

Since all OSes only allow you to customize your patterns for the current OS locale, and Gecko apps have their own locale selection, I believe that the ultimate solution would be to add some form of "regional settings" in Gecko, so that you can customize your date/time for the app UI locale if you use different app locale from the OS locale.

> though I still shake my head about the decision made by Mozilla

I hope my explanation above sheds some light on it for you. Internationalization is complex. Messing with locale selections and cross-selections usually makes the end result very limited. As much as I understand that it worked for you, I hope the explanation above may help you see how it doesn't scale.
> Let's say you get en-US Thunderbird on French OS and instead of Tuesday you get "dd/mm/yyyy".
> That of course, in en-US will be "mm/dd/yyyy", but when resolved will look like "Today is 03/04/2017"
> - I hope you realize that this is very  confusing to a user who doesn't know that we pick up
> translation from your app UI locale, but date from your OS locale.

Yes, it would be very confusing, but this is what we get with your new code.

So far, we used the OS date/time format, which on a French OS would be "Today is 15.04.2017", which is exactly what the user expects. This is the date format he knows and wants to see.

No French or German user wants to see "Today is 15/04/2017" nor "Today is 04/15/2017", both are wrong for them. But this is what you get when you use the app UI locale for date formatting. That's what we're complaining about.

The places where we use words in dates are the exception. In all most all places, and esp. in the prominent places, we're using short date and time formats without words for weekdays or months. E.g. https://bug1354339.bmoattachments.org/attachment.cgi?id=8856814 So, it's more important to write the short format in the format that I am used to seeing, than to get the words right, in those few places where they are used.

If you want to use the app locale for week days and months, and you can pull that off somehow, I have no problem with that. it would be nice. But the date format - that is, the order of elements, and the delimiters - must be what is configured in my OS. That's what I see everywhere else in my applications, and that's what I expect as user.
WalterGR, you're the reporter. Could you please check a nightly, to see whether you're satisfied with what you see?
If not, please REOPEN the bug. As a reporter, you have the right to do so, if you think this bug is not fixed.
Lightning before/after
Comment on attachment 8858464 [details]
Lightning before/after

German OS and date/time settings, en-US Thunderbird
Attachment #8858464 - Attachment description: tb-datetime-format.png → Lightning before/after

Updated

2 years ago
Summary: System date and time formats are not respected (all platforms) in TB 54 → System date and time formats are not respected (all platforms)
> No French or German user wants to see "Today is 15/04/2017" nor "Today is 04/15/2017"

Now replace French user with Arabic OS user and look at the same example. Please, take your time,  I'll wait. As you're crafting the example, make sure to take into account the directionality of the phrase vs the date.

French and German user should not use a locale they don't want to use.

I honestly believe that at this point it doesn't make sense to beat a dead horse.

I presented my motivation clear. You're continuously responding with "but it's what I want". Internationalization is not about solving a particular combination of two locales (de/en-US in your example) but *any* combination of locales. Unless you can suggest a solution that will provide a consistent experience across directionalities, languages and cultures that covers any combination of OS locale and UI locale, I don't believe you're in a position to talk about what should be done.

Comment 29

2 years ago
(In reply to Ben Bucksch (:BenB) from comment #27)
> German OS and date/time settings, en-US Thunderbird
Looks terrible. It just goes to show that we're still working on getting things consistent:
Bug 1346549, bug 1313659 and bug 1356403. And for Calendar: bug 1229684.
Calender does all/most of its date/time formatting itself, so if it's not right, file a bug in Calendar.
I can see in the picture:
9:00 PM - 4/7/17. Clearly en-US formatting. Inconsistent is the 18:00/19:00 (which doesn't match the 9:00 PM? Why?) which comes from a sophisticated time picker.

I have en-GB times everywhere, so I see:
18:00 - 19/01/2015 - 18:00, so I'm pretty cool for now ;-)
I get the impression that some of the developers here are not familiar with the particular ways Mac OS X handles locales. Let me clarify:

1. The user can set preferences, system-wide, for a preferred language (actually a list of languages, ordered by priority), a perferred date format and a preferred number format. All these can be set _independently_ - and I guess that's a bit unexpected to the decision makers at Mozilla, I can imagine?

2. The user can even go so far as to customize the date and number formats. For instance, English default for numbers is "1,000.34" for one thousand and 34/100. German default: "1.000,34". Yet, he could set it to "1'000,34". That means he's not bound to using fixed settings.

3 On the API level, a regular Mac app does NOT known about an explicit locale setting such as "en_US" and pass that around. Instead, the APIs for date and number formatting use the "default locale" reference. Here's a code example explaining this:

https://developer.apple.com/library/content/documentation/CoreFoundation/Conceptual/CFDataFormatting/Articles/dfCreatingCFDateFormatters.html#//apple_ref/doc/uid/TP40002339-SW1

As you can see there, you'd call CFLocaleCopyCurrent(), and that would not even tell you whether it's "en_US" or something else. It's an internal placeholder for whatever the user has set as his system-wide preferences.

Same for the displayed language in menus, labels etc, though you do not even need to fetch the locate reference there, but simply call CFCopyLocalizedString or NSLocalizedString, and it'll look into your app's various localized strings files, and pick the one that comes closest to the language choices the user made system-wide.

This all means that there is not a single locale, and that Mac apps are not bound to fixed locale codes, either.

To get this right in Mozilla apps, a similar mechanism may be needed. If the Mozilla framework DOES carry explicit locale parameters around to pick a formatting, then maybe a new meta code should be defined that means "use user's system-wide preference", and that code would be used on Mac versions of the apps, unless the user explicitly changes it to an explicit locale. Then, the lower level, where the formatting is done, the code would perform a special case for this special locale, only on Macs, and then use the aforementioned Mac APIs to format the values.
> Please, take your time,  I'll wait.

Please drop the arrogance and listen to others. Plenty of users and developers, in many different bugs, told you that you're wrong.

> As you're crafting the example
[mixing LTR and RTL]

I'm not crafting obscure theoretical examples, but I am talking about real-world examples of many many of users, probably millions. Many in Germany use English software. But hate English date formats.

If you want to make an exception for mixing LTR and RTL, that might be OK, I can't speak about that. I can speak about en-US on German and French OS, and current behavior there is totally, absolutely wrong, and goes against all cultural expectations.

And against all previous behavior, both Mozilla and all native apps on all platforms.

> French and German user should not use a locale they don't want to use.

Don't tell users what to do, but do what they want.

Plus, all operating systems, every single one of them, disagrees with you.

You keep are mixing language and region and date/time formats. This is wrong. As every OS and all native Windows and Linux applications separate them.
> Please drop the arrogance 

Sorry for that personal comment, I retract that.

ZiBi, I understand your reasoning and where you're coming from. You've worked with this for a long time, and you've seen plenty of edge cases that look wrong. You're trying to fix those. You're trying to be correct. I understand hat.

However, you're missing the big picture: That of the end user. The app is not seen in isolation, but in context of the user and his system and the other applications on his system. I see German date/time format everywhere, have always seen it in Firefox/TB, and expect to continue to see that, even if I use English builds. All other apps do the same, so why should FF be different? Frankly, I don't care, if I see "The certificate expires on Dienstag, 25. März 2018" in an obscure cert dialog 3 levels down. I can read both English and German, and only I see that, so that's fine for me, even if a little funny. But I do care very much that I see my preferred (and configured) date format in the Thunderbird message list, in Lightning, and everywhere else.

Please know that there are many like me who use English builds on a German or French OS.

Comment 33

2 years ago
Everyone is different. I use en-US Windows on all my machines since I'm a computer professional ;-) and when I need to resolve problems, searching for solutions with English error messages is just so much more useful.

I know people in other European countries who use English Windows since they think that any other language for computing just s*cks.

I was quite annoyed when I couldn't get en-GB dates to show in the en-US versions, but that's fixed so I'm happy now.

IMHO there are two categories: Plain users who want everything in their language. My wife, she has everything in Spanish. And geeks, they should use English-everything. Both those cases work. I'd go crazy on a German or French OS (or keyboard).

Personally, I'd say that any software showing "The certificate expires on Dienstag, 25. März 2018" is not properly localised.
Jorg, did you read my last explanation? Probably not, or you should know by now that a Mac user would be able to set it up so that he'd get either "The certificate expires on Tuesday, 25. March 2018" or "... expires on 25.3.2018", if he cares about not mixing English text with German written weekdays and months. Yet, they'd use the proper German order. So, your argument does not apply.

And this does not only apply to dates but to times as well. Most of europe uses 24 hour times, yet, I suspect that I'll end up with a 12 hour am/pm display when using an English Mozilla apps, won't I (correct me if I'm wrong).

Comment 35

2 years ago
Sorry, I haven't read your comment #30 in detail since it was all about Mac.

On Windows, with en-US FF/TB you get 12h AM/PM unless your locale is en-*, in which case the OS setting is used. I can't speak for other platforms.
Thomas, I have read it, together with an implication that maybe I don't know what I'm talking about.  :)

> 1. The user can set preferences, system-wide, for a preferred language (actually a list of languages, ordered by priority), a perferred date format and a preferred number format. All these can be set _independently_

Incorrect.

A user can set a fallback chain of locales constructed out of language priority fallback list and a single set of regional settings, which can be, on top of that, customized to users needs.

It's a really good use of BCP47 and LDML standards (Mac uses ICU/CLDR just like we do) allowing user to create a fairly sophisticated list of locales, for example: ["en-DE", "fr-DE", "pl-DE"].

The different between what you stated and what I'm stating here is that user cannot, however, adjust regional settings for any region separately. You select a region and then adjust settings for it.
If you change your region, your manual adjustments get reset together with an update to the new set of regional settings - default CLDR data for the new region you selected.

That still puts MacOS user in a really comfortable position and the fact that Mozilla and Apple work together on ICU/CLDR gives a really nice benefit - you can do what you want on Mac (while Windows/Linux/Android users cannot yet) - you can select English language, and then select German regional settings, and then if you have English Firefox, we will pick up those settings!

> 3 On the API level, a regular Mac app does NOT known about an explicit locale setting such as "en_US" and pass that around. Instead, the APIs for date and number formatting use the "default locale" reference.

Which, if you go through the Cocoa API and their Interntionalization docs, is to be used if you app is using Mac OS UI locale. But Mozilla is not. We have our own locale selection and you're meant to use your product in the locale you downloaded. Soon, and that is part of my work, you will be able to select a locale for your product "on fly" and we'll download locale resources for you.

But the bottom line is that Gecko app can live in it's own locale. It can also follow OS locale, but we don't have yet a mechanism to make it easy to download resources for the OS locale, so if you install "en-US" Thunderbird you only have "en-US" resources, so Gecko's language negotiation will never end up with "de". 
Once we're done, Gecko will be able to download "de" resources on fly and switch your Thundebird to "de". (or, "de-DE" to be specific).

Bottom line is, Thomas, I believe you can pick up "de" region in Mac OS, and Thunderbird will allow you to follow your regional preferences.
But I also believe that you're not correct about how Apple API works on with regards to applications that do use their own locale settings, and Gecko apps happen to be in that group.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #28)
> > No French or German user wants to see "Today is 15/04/2017" nor "Today is 04/15/2017"
> 
> Now replace French user with Arabic OS user and look at the same example.
If the sentence is "Expires on: 06/04/17", who outside the US will recognize that this means June 4th. The vast majority people are not aware of that difference.

> French and German user should not use a locale they don't want to use.
It's not about French and German in the first place, but locales for which there is no Firefox localization. E.g. Windows 10 had 110 languages available on launch (according to Wikipedia, language packs available at https://support.microsoft.com/en-us/help/14236/language-packs ) and there are more languages available for datetime, currency etc. settings.
There are also native speakers which use en-US Firefox for various reasons, e.g. not expecting that there is a Firefox version for their language available (you have to download Firefox from an already localized different browser to get the localized version), bad experience with poorly localized software in the past etc. E.g. 32% of the Dutch Firefox users use an en-US build and 06/04/17 is an uncommon format. The top 15 countries which use en-US builds can be found at https://irccloud.mozilla.com/file/HeYJLyzi/newplot.png

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #23)
> > It should be clear that no other native app for the Mac behaves like that, even if it's not localized for the language the date locale uses.
> 
> I believe that absolutely every app that allows users to select the UI
> locale does it.
This might depend on short vs long formats, e.g. "Saturday, April 15th" might be used, but what program shows en-US dates like "06/04/17" and ignores the OS setting?
Zibi, thanks for reading my comment and clarifying a few things. That tells me that at least the issue is looked at and fairly well understood, and I can leave it to the Mozilla devs to make the best of it. I wrote my comment because I had the impression that there was a lack of understanding before.

I may also have gotten the internal workings of the Mozilla framework wrong, and what you say even sounds like TB should get our German region-specific dates, times and numbers right, yet it doesn't, and I don't understand why. You say "I believe you can pick up "de" region in Mac OS", but from the other comments I gathered that exactly that doesn't work.

But I will widthdraw from this discussion now since I believe I've helped as much as I could to resolve this, and I leave others to work this out. To me, as long as TB cannot show German dates and times in with English language, I will not use it, and keep using Mail (which is the smaller pain to me, then :)
> I may also have gotten the internal workings of the Mozilla framework wrong, and what you say even sounds like TB should get our German region-specific dates, times and numbers right, yet it doesn't, and I don't understand why. You say "I believe you can pick up "de" region in Mac OS", but from the other comments I gathered that exactly that doesn't work.

The patch that fixed it landed just a couple days ago. Sorry for not clarifying that.

If you will see this bug on nightly over the next days, please, file a new bug and I'll look into it.

If you language of OS matches the language of Mozilla app UI, then we should pick up your regional settings on MacOS.

Comment 40

2 years ago
I do not get it from user point of view. 

I'm using US Windows 10, but with locale set to Russian. Every _EVERY_ program respects that, but not Firefox/Thunderbird anymore.

See the dates and partal sentences in Russian. All are happy with it. When I have set locale of the OS to 12.01.2017,
then I assume that I always see the 12th Januar. 01/12/2017 would mean for me 1st December.

Examples:

Microsoft Windows Calendar
https://www.dropbox.com/s/uq9ivb2xpsqvsp8/%D0%A1%D0%BA%D1%80%D0%B8%D0%BD%D1%88%D0%BE%D1%82%202017-04-24%2016.31.43.png?dl=0

LibreOffice US
https://www.dropbox.com/s/mt66bt5arv30oyr/%D0%A1%D0%BA%D1%80%D0%B8%D0%BD%D1%88%D0%BE%D1%82%202017-04-24%2016.35.06.png?dl=0
> I'm using US Windows 10, but with locale set to Russian. Every _EVERY_ program respects that, but not Firefox/Thunderbird anymore.

Thanks for the example. I'll look into the MS Windows Calendar today and will try to reach out to MS Intl people for comment on the behavior.

Comment 42

2 years ago
Windows Mail is using the right locale as well. See the time format - 21:20, not the 9:20 PM, that TB is now showing.

https://www.dropbox.com/s/wklsw83hx40wx74/%D0%A1%D0%BA%D1%80%D0%B8%D0%BD%D1%88%D0%BE%D1%82%202017-04-24%2021.20.50.png?dl=0
Ditto in .NET / Windows Presentation Framework. App is US-English, German OS, Dates show as "27.04.2017", time shows as "22:58", as expected.
Just an update on my progress here.

I'm still reviewing the HIG of the major 3 desktop platforms.

I'm fairly certain we have a good defaults for Mac and Linux, but I'm still waiting for feedback from Microsoft Intl team on the inconsistency between their API and what Eugene showed in Windows Mail in comment 42.

I want to finalize this work in time for 55 merge day so we have around 5 weeks to review that and finalize. The good news is that irrelevant of the decision the patch should be simple.

I'll file bugs and notify everyone here once I'm ready.

Comment 45

2 years ago
While we're waiting, perhaps dedicate some cycles to bug 1355977 ;-)

Comment 46

2 years ago
(In reply to Ben Bucksch (:BenB) from comment #24)
> > Let's say you get en-US Thunderbird on French OS and instead of Tuesday you get "dd/mm/yyyy".
> > That of course, in en-US will be "mm/dd/yyyy", but when resolved will look like "Today is 03/04/2017"
> > - I hope you realize that this is very  confusing to a user who doesn't know that we pick up
> > translation from your app UI locale, but date from your OS locale.
> 
> Yes, it would be very confusing, but this is what we get with your new code.
> 
> So far, we used the OS date/time format, which on a French OS would be
> "Today is 15.04.2017", which is exactly what the user expects. This is the
> date format he knows and wants to see.
> 
....

What compounds the issue is that not all flavours of Thunderbird are offered. I live in Canada, have a Windows system localized for Canada–français (French-Canada), and as such, dates are displayed as "yyyy-mm-dd", with is ISO-8601. The century information is quite important because we also see a lot of dates in the European French and U.S. formats.

If all my appointments show as "03-04-17" such as happens with Thunderbird 54, then Thunderbird becomes unusable.

Two solutions: 
1. Use the previous system – it worked.
2. Prepare many more localized versions. Just for French, 3 to 5 differently localized versions would be needed just to provide the properly expected behaviour.
Thanks for the input Michel!

Can you verify if your use case is fixed in 55? If your Windows is "fr-CA" and you Thunderbird is "fr" or "fr-FR", the OS regional preferences should be picked up.

(I'm almost done evaluating the status of other products and will file a bug for cross-language mappings today hopefully as well)

Comment 48

2 years ago
I agree that TB 54 is pretty much unusable if you want anything that isn't the build/app locale default. TB 55 is usable since I fixed bug 1351427.

If you use an en-US version of TB, you can use *any* en-* locale offered by the OS and any of it's date/time formats.

On Windows 7, en-GB offers: dd/MM/yyyy, dd/MM/yy, d/M/yy, d.M.yy and yyyy-MM-dd.

If you use a French build/app looking at French (Canada) in Windows you have yyyy-MM-dd, dd/MM/yyyy and a few others.

I really don't understand why one of those setting wouldn't satisfy you. The only people affected here are en-US users who what to see German dates, and that's not possible. 

Since you mentioned appointments: The calendar code that formats those is still not fixed, you should go an lobby over in bug 1360915.
> TB 55 is usable since I fixed bug 1351427.

No, it's not, because you deliberately and specifically excluded me. I have a German OS and want German date formats, and use en-US builds. Thunderbird and Lightning is now unusable for me.

You fixed Canadians and Australians and British, yes.

But bug still exists for everyone around the world who uses English software and is not in an English region and uses other date formats.

Comment 50

2 years ago
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #47)
> Thanks for the input Michel!
> 
> Can you verify if your use case is fixed in 55? If your Windows is "fr-CA"
> and you Thunderbird is "fr" or "fr-FR", the OS regional preferences should
> be picked up.
> 
> (I'm almost done evaluating the status of other products and will file a bug
> for cross-language mappings today hopefully as well)


Sorry for the delay, it took me time to find TB 55. I finally found it (version dated 2017-05-19).

1. In Thunderbird itself, the regional preference has been picked from the system. 
In the message list, the date appears as "2017-05-17 à 23:00" (litteraly aaaa-mm-dd at HH:mm), whereas it previously appeared as "2017-05-17 23:00".
The "à" widens a bit the column, compared to what it was previously, but that's a minor issue.

In the integrated calendar, however, the date appears as "dd/mm/yyyy HH:MM" (ex.: 17/05/2017 18:30). It's not totally horrific because I at least have the century information to guide me, but it still looks quite strange. The integrated calendar has a few other issues, however, as I lost all access to my Google calendars (even with the "Provider" extension) and other online calendars (webcal) had missing information.

Comment 51

2 years ago
So you're using French Windows and French TB? "à" is the official ICU connector for joining date and time.

Calendar/Lightning is still broken, see bug 1360915.

Updated

2 years ago
See Also: → bug 1371325

Comment 52

2 years ago
TB 55.0b1 finally reached the Thunderbird Next repo for Ubuntu 14.04, allowing me to install and test. It is still not formatting dates to en_DK.utf8 from my LC_TIME setting as I expected it to.


Expected format:
"2017-06-17 13:04"

Actual format:
"6/17/17, 13:04"

Comment 53

2 years ago
So I assume you installed and en-US version? And yes, it should respect settings for en_DK although I wonder since when English has been an official language in Denmark. I assume you're talking about the date/time display in the thread pane, the Date and/or Received columns, right? Other spots in the application are still wrong and we have a few bugs covering this:
Bug 1346549, bug 1313659, bug 1356403 and bug 1360915.

Comment 54

2 years ago
Oh, LC_TIME, what happens if you set LANG? I'm not sure which of the various Linux locales is used.

Comment 55

2 years ago
Testing from the CLI using 'LANG=en_DK.utf8 thunderbird' had no effect on the date format.

Comment 56

2 years ago
Works fine on Windows, Zibi, how is this meant to work on Linux?
Flags: needinfo?(gandalf)
This is a pretty long discussion on a RESOLVED bug - shouldn't it be reopened?

Comment 58

2 years ago
The discussion has moved to bug 1366134.
> Works fine on Windows, Zibi, how is this meant to work on Linux?

On Linux we do a very basic logic. We use icu_getDefaultLocale to get the OS locale and on Unity/Gnome we look for 12/24 hour clock gsetting. That's it.

There's more conversation going on about how to improve it on Unix/Linux - bug 1337069.
Flags: needinfo?(gandalf)

Comment 60

2 years ago
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #59)
> On Linux we do a very basic logic. We use icu_getDefaultLocale to get the OS
> locale and on Unity/Gnome we look for 12/24 hour clock gsetting. That's it.
> 
> There's more conversation going on about how to improve it on Unix/Linux -
> bug 1337069.

@Zibi: GNOME Shell displays 24h dates to me, but Thunderbird insists on
showing 12h dates. What am I doing wrong? What's the gsetting?

Tb 56.0b2-build1 on Arch Linux; I'm coming here from Bug 1389369.

Updated

2 years ago
Flags: needinfo?(gandalf)
@Ronan: did you mark the 24h manually or is it automatically following your GNOME Shell locale?

Gnome allows us to recognize if the user set 12/24h manually, or is he following his locale default.
If the user set it manually, we follow it. If the locale is the default for Gnome locale, we follow the default for ours.

Try going to Settings for Date/Time and manually flipping to desired state. Then reload Thunderbird.

If you have dconf-editor, go to org.gnome.desktop.interface and see if the value for clock-format is 12 or 24 and if "use default value" is on or off.

In order to enforce Thunderbird to follow your format, you need for Gnome and Tb locales to match *or* you need to explicitly set the clock-format to desired state manually.

Hope that helps!
Flags: needinfo?(gandalf)
For me the dconf-editor clock-format is set to 24h (which I'd say is the default). 
In the Thunderbird preferences I set it to use Regional settings locale: English (United states) 

The desktop is in English, Thunderbird is in en-US.

But, I still get the American AM/PM time and date format. System settings are really set to display time and numbers as Swedish (Finland).
Magnus: Can you file a new bug please? It seems like a new bug and I'd like to tackle it separately.

In that bug, can you please provide a screenshot of the System Settings that show the Display Time and Number set to Swedish(Finland). Thank you!

Comment 65

2 years ago
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #61)
> @Ronan: did you mark the 24h manually or is it automatically following
> your GNOME Shell locale?
> 
> Gnome allows us to recognize if the user set 12/24h manually, or is he
> following his locale default.
> If the user set it manually, we follow it. If the locale is the default
> for Gnome locale, we follow the default for ours.
> 
> Try going to Settings for Date/Time and manually flipping to desired state.
> Then reload Thunderbird.
> 
> If you have dconf-editor, go to org.gnome.desktop.interface and see if the
> value for clock-format is 12 or 24 and if "use default value" is on or off.
> 
> In order to enforce Thunderbird to follow your format, you need for Gnome
> and Tb locales to match *or* you need to explicitly set the clock-format
> to desired state manually.
> 
> Hope that helps!

That helps! Dconf pref was set to follow locale default. After explicitly
setting to '24h' and restarting Tb, Tb shows 24h dates \o/ . Thanks!

Updated

a year ago
See Also: → bug 1389972

Updated

a year ago
Duplicate of this bug: 1426907
You need to log in before you can comment on or make changes to this bug.