Closed Bug 1354339 Opened 8 years ago Closed 8 years ago

Dates are displayed in US format in the places treeview instead of using the current OS format

Categories

(Core :: Internationalization, defect, P1)

Product:
Core
Component:
Internationalization
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1343768

People

(Reporter: markh, Unassigned)

Details

(Keywords: dogfood, regression, Whiteboard: [dogfood])

User Story

In a scenario where the OS locale is different from Firefox UI locale, the History and Bookmarks windows display date format using UI locale, which may be ambiguous.

An example when it's ambiguous is when the OS is in en-AU (Australian English) and Firefox is in en-US.

In that case the date "02/03/2017" may mean either 2nd of March or 3rd of February.

Attachments

(3 files)

Screenshot comparing Gecko 52 and Gecko 55, exposing bug
46.48 KB, image/png
Details
simple patch for 54
873 bytes, patch
mak
: review-
Details | Diff | Splinter Review
fix-mix.PNG
131.85 KB, image/png
markh
: feedback+
Details
STR: * Install Firefox on a computer configured as being in Australia (or any place configured to display dates as DD/MM/YY, which IIUC is pretty much anywhere other than the US) * Open bookmarks or history, look at the dates displayed. Expected: * They are displayed as DD/MM/YY Actual: * They are displayed as MM/DD/YY, meaning dates like "04/01/2017" are completely misleading. Note there are no en-au builds available. Note also that this is true for people using en-us builds everywhere in the world other than the US. This is currently on beta. While people in the US are not affected, people not in the US would consider this a serious regression. I believe this is blocked by bug 1351427, or an alternative may be to change how the dates are displayed there from DD/MM/YY to dd-mon-yyyy, as is done in "save logins" for example. I believe this should not go to release in the current form.
I do not actually believe that this is blocked on bug 1351427. Majority of dates in Firefox UI use JS so they just should start using mozIntl.DateTimeFormat. This should also have nothing to do with Beta, since I believe that the changes from OS locale date/time formatting to UI locale date/time formatting landed in 54 (current Aurora). As much as I recognize this as a flaw, I'd like to point out that the number of users affected is rather low - we're talking about users in regions that do not have their version of Firefox. If you take "en" language as an example, we have en-US, en-GB and en-ZA. We're working toward completing the feature set for those regions, but I believe we should not blow it out of proportion.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #1) > This should also have nothing to do with Beta, since I believe that the > changes from OS locale date/time formatting to UI locale date/time > formatting landed in 54 (current Aurora). I'm not completely clear on what changes landed when, but the bug as described exists on 53.0b9. > As much as I recognize this as a flaw, I'd like to point out that the number > of users affected is rather low - we're talking about users in regions that > do not have their version of Firefox. If you take "en" language as an > example, we have en-US, en-GB and en-ZA. That seems a very US-centric view to me and I can't agree that English speakers in locales other than the 3 listed above aren't important enough to let a bug like this go to release. I'd also be interested in figures for en-us downloads in locales other than those listed before we categorize the number of impacted users as "rather low". It's not simply an inconvenience - seeing a date of "04/01/2017" without additional context (eg, being lucky enough to also see a date of "01/13/2017") is simply and plainly wrong for those users.
OS: Unspecified → All
Hardware: Unspecified → All
To get the DD/MM/YYYY display and 24h times you need to do the following: When using FF 53.x you need to set "Region and Language, Format" to "English (United Kingdom)" in the Windows control panel due to bug 1301640, since system-set formats other then the "format locale" are ignored. When using FF 54.x, you need to use an en-GB localised version of FF. Sadly ICU/CLDR doesn't provide 24h times for Australia since "The 12-hour notation is the most common in Australia." (https://en.wikipedia.org/wiki/Date_and_time_notation_in_Australia). I'd disagree with that ;-)
I'm not sure if bug is the best place to hold the conversation about it anymore, since I'm afraid you question several fundamental assumptions, rather than implementation details. Assumptions such as: - software should follow locale it has been localized to - people should use software in locale they chose and expect it to "do its best" to display everything in this locale etc. > It's not simply an inconvenience - seeing a date of "04/01/2017" without additional context (eg, being lucky enough to also see a date of "01/13/2017") is simply and plainly wrong for those users. The context in which you're seeing this date is "You installed en-US locale software". Locale is a multi-bit package that defines the language and the region you get the software in. In this case, you installed "en" language, and "US" region software. I believe you have every right to expect this software to display UI in both "en" and "US". So, for the small population of users who are in your position, it's a variant of https://xkcd.com/1172/ You had your workflow - en-US, which didn't do "US" - and it worked the way you liked it. Now, we fixed the part about not following "US" (as part of a bigger shift) and now your workflow is broken. Ultimate fix is to transition to use mozIntl.DateTimeFormat which combines the UI locale with regional settings alternations giving you the right mix. > That seems a very US-centric view to me and I can't agree that English speakers in locales other than the 3 listed above aren't important enough to let a bug like this go to release. I'm sorry, my intention was not to sound "US-centric". My intention is to point out, that a scenario where a user is in one locale, his/hers OS is in another, and we don't offer Firefox in his/hers locale, is an edge case. And, once again, I'm not saying we shouldn't fix their use case - in fact, I just spent several months working on the fix (bug 1339650 and dependencies). > I'd also be interested in figures for en-us downloads in locales other than those listed before we categorize the number of impacted users as "rather low". I'd be interested in that as well! Realistically, I don't believe we can fix that before 55. In 55 we have the new API and we have 8 weeks to transition code to use it which is the earliers I can see us improving date/time handling to adjust to regional settings from the OS. > Sadly ICU/CLDR doesn't provide 24h times for Australia since "The 12-hour notation is the most common in Australia." Which means that Windows, MacOS, Chrome and Android will display 12h time format in Australia. If you disagree with that, you should file a bug in CLDR. Also, in 55 we added the code to respect your regional preferences, so once we transition to it, the dates in Firefox will use the format you chose in your OS, but localized to the locale of your UI.
(In reply to Jorg K (GMT+2) from comment #3) > To get the DD/MM/YYYY display and 24h times you need to do the following: > > When using FF 53.x you need to set "Region and Language, Format" to "English > (United Kingdom)" in the Windows control panel due to bug 1301640, since > system-set formats other then the "format locale" are ignored. To be clear, mine is set to "English (Australia)" and I'm getting the wrong format in 53. Are you saying that all users in Australia should change their region to be "English (United Kingdom)" to avoid this regression? > When using FF 54.x, you need to use an en-GB localised version of FF. So users in Australia are expected to know to uninstall their current version, go to https://www.mozilla.org/en-US/firefox/new/, ignore the big green "Free Download" button and instead select "Firefox for Other Platforms and Languages", ignore all the download links on that page and select "Available Languages", scroll down to "English (British)" and download that? (Obviously that's a rhetorical question - no one would sanely expect that) > Sadly ICU/CLDR doesn't provide 24h times for Australia since "The 12-hour > notation is the most common in Australia." > (https://en.wikipedia.org/wiki/Date_and_time_notation_in_Australia). I'd > disagree with that ;-) 24 hour times are almost never used in Australia. Regardless, control panel would allow you to configure your times that way if you choose.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #4) > I'm not sure if bug is the best place to hold the conversation about it > anymore, since I'm afraid you question several fundamental assumptions, > rather than implementation details. It seems to me the tl;dr of this comment is "you are wrong to expect Firefox to honor your locale preferences. There are only 3 English builds, if you live anywhere else in the English speaking world, you aren't worth worrying about, so the best advice is to try and work out what locale differences exist in those 3 builds and work out which one is less pain. The fact we used to do this correctly, and the fact that all other software does this correctly is of no consequence. However, we are going to fix it in 55." > So, for the small population of users who are in your position, it's a > variant of https://xkcd.com/1172/ Wow. Just wow.
:markh, I find your tl;dr misrepresenting my position, passively aggressive, assuming bad intentions and unproductive. Please, read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html In particular: - I did not stated that "you are wrong to expect Firefox to honor your locale preferences" - in fact, I stated the opposite. - "if you live anywhere else in the English speaking world, you aren't worth worrying about" - that's also not something I stated and it does misrepresent my position - "so the best advice is to try and work out (...)' - nope, didn't say that either. If you ask me, the best way is to write patches for this bug :) - "The fact we used to do this correctly" - we didn't do "that correctly" - we did it in the way that served your use case and kept other use cases that you probably don't consider valid, since they're not yours, broken. - "However, we are going to fix it in 55." - it's worse than that. You may have to do what open source does since forever and channel your passion for this fixed into writing patches yourself. Otherwise you may have to rely on prioritization of bugs by the Intl team. As I stated before, this use case deserves to be fixed and will be. It's one of many use cases. > Wow. Just wow. I recognize that it's surprising when we learn that the workflow we have is not the most common workflow, and the problem that we experience that we believe "could be just fixed by doing what I want" is more complex and intertwined than expected. Please, don't let it affect your communication. ======================= Shifting to discuss how to fix it - I updated the title to be actionable, and am going to file follow-ups that scope the patches to be written.
Summary: Many dates are displayed in US format instead of using the current locale → Use mozIntl.DateTimeFormat for all date/time formattings in Firefox
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #7) > :markh, I find your tl;dr misrepresenting my position, passively aggressive, > assuming bad intentions and unproductive. That's unfortunate but was not my intent. > > Wow. Just wow. > > I recognize that it's surprising when we learn that the workflow we have is > not the most common workflow To be clear, the surprise was that someone visiting https://www.mozilla.org/en-US/firefox/new/, downloading the offered software and expecting dates to be formatted correctly is categorized as "not the most common workflow" and that it has any relationship to the point being made in that xkcd comic. > Shifting to discuss how to fix it - I updated the title to be actionable, > and am going to file follow-ups that scope the patches to be written. Thanks - but given you are filing other bugs which are actionable, I changed the title back so it's easier for people to find when they notice the obvious regression.
Summary: Use mozIntl.DateTimeFormat for all date/time formattings in Firefox → Many dates are displayed in US format instead of using the current local
> To be clear, the surprise was that someone visiting https://www.mozilla.org/en-US/firefox/new/, downloading the offered software and expecting dates to be formatted correctly is categorized as "not the most common workflow" You're, I must assume on purpose, leaving out all the details about the particular scenario. As I'm sure you know, we offer Firefox in 80 locales, and for anyone in those locales (locales - not languages - locale is a combination of language and region), it will just work (tm) and that's the most common scenario. Since I assume you know what you're doing here, I will not take the bait. > Thanks - but given you are filing other bugs which are actionable, I changed the title back so it's easier for people to find when they notice the obvious regression. sgtm.
Another problematic use case, is Nightly Testers. I don't expect Nightly to be available in my locale immediately, since localizers are for the most part volunteers, but I'd expect Nightly to give me dates I can read. We want to grow Nightly population, not to shrink it. To go back on track, basically we need to replace Intl.DateTimeFormat with mozIntl.DateTimeFormat to get OS-based time format? I'll file a bug to fix the Library then.
ah, bug 1354445 is doing that already! cool. Which version we can uplift that to?
> I don't expect Nightly to be available in my locale immediately, since localizers are for the most part volunteers We offer Nightly in many locales - https://www.mozilla.org/en-US/firefox/nightly/all/ - and we should be able to add more. > Which version we can uplift that to? I'm afraid none since mozIntl.DateTimeFormat landed in 55.
(In reply to Mark Hammond [:markh] from comment #5) > To be clear, mine is set to "English (Australia)" and I'm getting the wrong > format in 53. Are you saying that all users in Australia should change their > region to be "English (United Kingdom)" to avoid this regression? Yes. I don't know how much of that is rhetorical, but yes. I had "English (Australia)" and I had to change that. I'm surprised, however, that FF 53 would give you MM/DD/YYYY on the en-AU locale. > > When using FF 54.x, you need to use an en-GB localised version of FF. > So users in Australia are expected to know to uninstall their current > version, go to https://www.mozilla.org/en-US/firefox/new/, ignore the big > green "Free Download" button and instead select "Firefox for Other Platforms > and Languages", ignore all the download links on that page and select > "Available Languages", scroll down to "English (British)" and download that? Yes again. Australian friends of mine do, since the want to see "Colour", not "Color": If you use the en-US version, |Tools > Options, Fonts & Colors| will say "Colors" and not "Colours". So the date format just matches that ;-( Look, I, being the Thunderbird maintainer, have discussed with Zibi in a handful of bugs. He finally convinced me and he's done a great job. Sadly, FF 53 and FF 54 are a little bumpy, as I have predicted on various occasions. Since the date/time information is displayed in Thunderbird in a very prominent place, our users are even more affected, see bug 1344594. Many people of the 24 million people in Australia use the en-US version version and have the trouble you're having, worst even, telemetry shows that 100% of users in India use the en-US version. And I believe they prefer the date/time format the Queen uses ;-)
User Story: (updated)
Summary: Many dates are displayed in US format instead of using the current local → Dates are displayed in US format instead of using the current OS format
Depends on: 1351427
See Also: 1351427 →
(In reply to Jorg K (GMT+2) from comment #3) > When using FF 53.x you need to set "Region and Language, Format" to "English > (United Kingdom)" in the Windows control panel due to bug 1301640, since > system-set formats other then the "format locale" are ignored. Ouch, I was mostly wrong. This comment only applies to C++ formatted date/times that we see in Thunderbird. In FF they are only used in the navigation history, where you don't notice the difference, since that only shows the weekday, and in certificate details. I've just downloaded FF 53beta and, for example, View Page Info says: May 31, 2016, 10:29:56 PM regardless of the Windows setting. That's not a C++ formatted date/time. I haven't tried an en-GB localised version.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #12) > I'm afraid none since mozIntl.DateTimeFormat landed in 55. How hard would it be to uplift at least to 54?
> How hard would it be to uplift at least to 54? Probably quite hard. I would expect it to require, among other things, uplifting quite a few mozilla::intl::OSPreferences changes, but I didn't look into it, so if you want to try, go for it. > View Page Info says: May 31, 2016, 10:29:56 PM regardless of the Windows setting. That's a result of change landed in bug 1301655 6 months ago. Should be in 52, 51 and 50 as well if I'm calculating correctly.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #9) > > To be clear, the surprise was that someone visiting https://www.mozilla.org/en-US/firefox/new/, downloading the offered software and expecting dates to be formatted correctly is categorized as "not the most common workflow" > > You're, I must assume on purpose, leaving out all the details about the > particular scenario. I'm not sure what you are referring to, but it sounds like you are assuming I'm acting in bad faith here - I'm not. IIUC, if I download Firefox in the UK (or maybe when my local region is set to UK?), I am offered the UK build. However (also IIUC), in the rest of the English speaking world I'm offered en-US. There's nothing on that download page to make us think the version offered isn't the version we should download. I'm not sure what part of that scenario I'm leaving out. > As I'm sure you know, we offer Firefox in 80 locales, > and for anyone in those locales (locales - not languages - locale is a > combination of language and region), Note that when downloading Firefox, there's an option that says "Firefox for Other Platforms and Languages". I believe most common users will not understand they should click on that link to download something in the same *language* but with different locale semantics. I also believe the vast majority of existing Firefox installations outside those 3 locales are using en-US today, and I don't believe it can be argued they did something wrong when installing it, nor that they are an edge-case. I'm only mentioning Australia because it's *not* en-GB - see above for the anecdote re India. > it will just work (tm) and that's the > most common scenario. I agree the most common scenario is probably people from the US downloading en-US - there's no disputing that. > Since I assume you know what you're doing here, I will not take the bait. As above, I'm not acting in bad faith - all I'm doing here is pointing out a serious regression for English speaking users who don't exactly match one of the 3 locales we support. Trying to frame this as the fact that they did something wrong when they downloaded Firefox is as likely to go down as well with them as it does with me. Pointing out that the "number of users affected is rather low" and that we are just "an edge case" just adds salt to the wound. Anyway, it seems we are talking past one another here and I believe I've made my point more than once...
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #4) > So, for the small population of users who are in your position, it's a > variant of https://xkcd.com/1172/ I don't think this is at all the case. You know, as many people have already reported, that wanting your OS date settings to be used is not by far an obscured use case. "Small population"? You're talking about 5-10% of the users world wide at the very least. Please don't take it as a personal attack on you or your work for pointing that out. On the whole this is valuable work, it's just that by not respecting OS settings you will loose more than you gain. IMO.
> I'm not sure what you are referring to I'm referring to the fact that we cover somewhere close to 90% of languages and locales spoken, which means that for vast majority of users we have the right locale. en-AU is not one of them. > in the rest of the English speaking world I'm offered en-US. There's nothing on that download page to make us think the version offered isn't the version we should download. Which is probably a bug in how we handle downloads on mozilla.org - ICU/CLDR assumes "en-GB" to be the default locale, not en-US. We may, for the very reason you pointed out, have to consider doing the same. > I also believe the vast majority of existing Firefox installations outside those 3 locales are using en-US today That's not true. I don't remember exact numbers, but 60-70% of our users do not use "en" Firefox at all. > all I'm doing here is pointing out a serious regression for English speaking users who don't exactly match one of the 3 locales we support. I did not assume bad faith, just the natural assumption that "my problem is very common" :) > Trying to frame this as the fact that they did something wrong when they downloaded Firefox is as likely to go down as well with them as it does with me. Well, it all started with "this must be elevated to P1 and backported 3 versions back" - kind of important, so I pointed out that it is an edge case to help with calibration of the urgency/priority. Notice, edge case is not less valid than common case, but it does impact how we prioritize problems. We have problems affecting 80 million users, and problems affecting 500k. Both are important for us, but we need to prioritize them. > You know, as many people have already reported, that wanting your OS date settings to be used is not by far an obscured use case. > You're talking about 5-10% of the users world wide at the very least. Please, show me the data that backs up your statement. > Please don't take it as a personal attack on you or your work for pointing that out. On the whole this is valuable work, it's just that by not respecting OS settings you will loose more than you gain. IMO. Thanks for this! I appreciate the humane aspect of this conversation :) I do not take this as an attack. I believe that people using multi-locale setups (OS in one locale, Firefox in another) or manually adjusting their regional preferences, are just very vocal about their habits and consider the workflow they use to be very important to them. That means that any change triggers several bugs with wording like this, which we have to evaluate and prioritize. I believe that the 3 dependencies listed should fix the workflow for most of them, and I'd appreciate help especially with the easy ones - bug 1354442 and bug 1354445
I think the fix is very simple: Anyone downloading from Australia, New Zealand or India should get the en-GB version. (In reply to Magnus Melin from comment #18) > .. it's just that by not respecting OS settings ... Fixed in FF 55, right?
At risk of being off-topic: mozilla.org doesn't have any geolocation capability on the download page (bug 1195080), it simply uses your accept-languages header, with some issues (bug 1290962). If your locale doesn't match any known locale, you end up with en-US, which is the default fallback language for all pages. Having said that, I have no idea what an OS set to English (Australia) sends as accept-languages if you use Chrome, Safari, or Edge.
Too late for a fix for 53, as we are heading into the last week of the beta 53 cycle and no one is assigned.
status-firefox53: affected → wontfix
tracking-firefox53: ? → -
(In reply to Francesco Lodolo [:flod] from comment #21) > Having said that, I have no idea what an OS set to English (Australia) sends > as accept-languages if you use Chrome, Safari, or Edge. as it happens i'm swimming in operating systems and browsers. MacOS 10.12.4 firefox 54.0a2 (2017-04-04) (en-US): en-US,en;q=0.5 chrome 57: en-GB,en-US;q=0.8,en;q=0.6 safari 10.1: en-au Windows 7 IE 11: en-AU netscape 1.22: (no accept-languages header) chrome 57: en-GB,en-US;q=0.8,en;q=0.6 Windows 10 Edge: en-AU,en-US;q=0.7,en;q=0.3 chrome 57: en-US,en;q=0.8 further into off-topic land: when i visit download firefox using safari on osx i'm offered the en-US version, likely because only en-au is in the accept-languages header so it defaults (incorrectly) to en-us instead of en-gb.
ZiBi wrote in comment 1: > the number of users affected is rather low You're *so* wrong about this. This affects *everybody* in the world who uses English builds and is not America. This is a massive regression, and must be fixed immediately. Most likely, by backing out bug 1342753. ZiBi, if you're not fixing this, and not backing out the offending fix either, then I will. This cannot stay as-is. This is massive breakage all across the platform, for many people.
Bug 1342753 has a patch that is called "Use app locale in DateTimeFormat.cpp, instead of OS locale". First, the fix was in the wrong code place. Bug 1342753 is about Places, but it was fixed in intl/locale/, thus affecting tons and tons of other code. Second, the whole idea of the fix is wrong. The UI language and the date/time formats are 2 completely different settings. Windows, for example, has an explicit setting for region, which is different from the UI language, and even allows the user to customize how dates and numbers appear. This Windows setting has existed since Windows 3.1, if my memory serves me right. Users rightfully expect that this value is used. Why is this so important? Because many people around the world speak English, and download software in English, meaning "en-US". Sometimes, e.g. for nightlies, it's the only language available. However, the US date format is totally braindead. Nobody in his right mind would write month/day/year, apart from Americans. The difference is particularly serious between British and American. Brits can use en-US apps in en-US without problem - color vs. colour doesn't matter. But brits write 1/4/17 for April 1st, while Americans write 4/1/17. If you show April 1st as 1/4/17 to a Brit or German, he will read Jan 4. British is just the most obvious case, but the en-US locale is used world-wide. I'm German and I often prefer installing en-US, even if German is available. But I absolutely, positively cannot stand US date, time and number formatting. There's a reason why Windows (and most other OS) have a specific date/time setting, separate from the UI language. You HAVE to use it. Everything else is just wrong. Apr 1 is 01.04.2017 for me, never 4/1/17, even if the app is in English. ------- All dates should follow the OS date/time settings, instead of using the UI language of the build to infer date/time format. Because the date/time settings are more specific than the global locale settings, and the UI language is even less specific than the locale. This has been how Firefox worked ever since it existed. You cannot just change this and tell people that they are all wrong. This change was in intl/locale/, and therefore broke a lot of code. The default must be to follow these specific settings of the user. If some code place really needs a different behavior, then that place can do that. But to follow the UI language (what you did here) is almost always wrong.
> You're *so* wrong about this. This affects *everybody* in the world who uses English builds and is not America. This is not the right place to discuss vague terms like "everybody is affected". If you want to make claims about the number of affected users or the scope of the regression, please use data. > This is a massive regression, and must be fixed immediately. The size of the regression is evaluated by the module owner and peers. > Most likely, by backing out bug 1342753. Backing out this patch will not fix it. > ZiBi, if you're not fixing this, If you take a look at the three dependency bugs for this one, all of them have patches that are being in the review process and have been added over the last 4 days. If you want to contribute to the conversation, please, familiarize yourself with the situation first. > and not backing out the offending fix either, then I will. This cannot stay as-is. I am not backing out anything at the moment, and I find your threats to back out someone's else patches from not your area of work not acceptable. If you'll continue breaching contributors guidelines and bugzilla etiquette, I'll request your account to be suspended. No single issue is more important than healthy non-toxic work environment in the project. If you have further questions about it, please, contact me directly and keep Bugzilla focused on technical conversation rather than emotional.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #26) > > You're *so* wrong about this. This affects *everybody* in the world who uses English builds and is not America. > > This is not the right place to discuss vague terms like "everybody is > affected". If you want to make claims about the number of affected users or > the scope of the regression, please use data. You mentioned in comment 1: "the number of users affected is rather low". In comment 4 "the small population of users". I'd like to know what data you used for those statements. > If you take a look at the three dependency bugs for this one, all of them > have patches that are being in the review process and have been added over > the last 4 days. If you want to contribute to the conversation, please, > familiarize yourself with the situation first. While it's great that work is being done here, Ben and I are concerned with the regression. IIUC, the patches you describe will not help with the regression, even if they mean the regression only exists for a few versions. > > and not backing out the offending fix either, then I will. This cannot stay as-is. > > I am not backing out anything at the moment, and I find your threats to back > out someone's else patches from not your area of work not acceptable. If > you'll continue breaching contributors guidelines and bugzilla etiquette, > I'll request your account to be suspended. It sounds like you are taking this far more personally than anyone intends. There's no question the work you have done and continue to do is valuable. However, it is reasonable to question whether that work should have landed when it causes this regression. > No single issue is more important than healthy non-toxic work environment in > the project. I agree, and I feel you are not taking our concerns seriously, and offering counter-threats to try and get someones account suspended isn't helpful in this regard. > If you have further questions about it, please, contact me directly and keep > Bugzilla focused on technical conversation rather than emotional. The fact we are pointing out a regression for a large number of users is a perfectly reasonable use of bugzilla. Attempting to hold us to standards which you don't hold yourself to (eg, "back up your claims with data", "don't threaten") isn't helpful when trying to look at this objectively, and helps create a toxic environment for us all. What's sauce for the goose is sauce for the gander.
> You mentioned in comment 1: "the number of users affected is rather low". In comment 4 "the small population of users". I'd like to know what data you used for those statements. Sure, vast majority of our users use the same OS and browser locale. Do you want me to calculate it from telemetry? > IIUC, the patches you describe will not help with the regression, even if they mean the regression only exists for a few versions. Where is that statement coming from? > It sounds like you are taking this far more personally than anyone intends. I am not taking it personally. I apologies if it sounds this way. > However, it is reasonable to question whether that work should have landed when it causes this regression. I agree. > I agree, and I feel you are not taking our concerns seriously I am taking concerns seriously. I'm also working on patches to fix them. I believe we'll have this fixed within 55 timeframe. The rest is not bugzilla-worthy, so I'll move it to IRC.
ZiBi, whatever you do, this needs to be fixed (or backed out) before this hits beta. > Backing out this patch will not fix it. I think I've shown in comment 25 why the patch in bug 1342753 was inherently wrong. It's simply ignoring the relevant settings now. And clearly, people depend on these settings, otherwise you wouldn't have us all up in arms here. We're just the first wave. > This is not the right place to discuss vague terms like "everybody is affected". > If you want to make claims about the number of affected users or the scope of > the regression, please use data. Huch? So, you're allowed to claim that "the number of users affected is rather low", but when many people from around the world tell you that you're wrong, and then *we* need data to back that up? > The size of the regression is evaluated by the module owner and peers. This is breaking applications. I think that speaks for itself. You've broken dogfood for me. I can't use the app anymore. This goes far beyond your module. > No single issue is more important than healthy non-toxic work environment in the project. If you would be listening to your fellow colleagues instead of minimizing us, we wouldn't have a problem. We have collectively a lot of experience, insight and viewpoints from around the world. You'd be wise to listen. Instead, you're insulting us, e.g. in comment 4: > So, for the small population of users who are in your position, it's a > variant of https://xkcd.com/1172/ I could even live with the insults. I cannot live with a US date/time format in my applications. > Do you want me to calculate it from telemetry? If you want to calculate it, check the number of users who use en-US builds and are not located in the USA (based on IP address). Almost all of them will be horribly confused and/or irritated by the US date/time format, because nobody outside of the US understand the format, or why anybody would write dates like that. If this is more than 0.1%, that's too much breakage. People will miss meetings because of this. > I'm also working on patches to fix them. How are you fixing this? Are you reverting the default of all APIs to return date/times in OS settings? > I believe we'll have this fixed within 55 timeframe. Sorry, but this is too late. It must be fixed in 54, because bug 1342753 is in 54. This cannot - under any circumstance, in any place in the UI - hit end users.
Keywords: dogfood
Whiteboard: [dogfood]
User Story: (updated)
I don't think it's very productive to continue this conversation in Bugzilla. I'd like to suggest the course of action: 1) Bugs that are the dependency of this bug will have to land. Bug 1351427 in particular should fix this regression in 55 2) For 54 I'll look into any possible way to fix it without re-regressing the behavior that the patch in bug 1342753 fixed. Please, if you want to discuss any personal topics, let's do this over email, not here.
Taking this as it'll likely have a different patch for 54 from the dependencies which will go to 55.
Assignee: nobody → gandalf
Status: NEW → ASSIGNED
Zibi, Bug 1351427 was misguided to start with. It states: > Expected Results: > Respect the language of build. This is wrong. This is never correct. The OS date/time format setting is more specific and always supersedes the UI language of Firefox. The reporter was confused. Probably his OS settings were misconfigured, and he didn't understand that. As such, bug 1351427 must be backed out to restore correct behavior.
Assignee: gandalf → nobody
Status: ASSIGNED → NEW
Depends on: 1355307
(Sorry, I accidentally reverted your changes in a conflict. Restoring.)
Assignee: nobody → gandalf
Status: NEW → ASSIGNED
Severity: normal → major
Priority: -- → P1
Ok, I debugged this bug. For the sake of the conversation I'm going to scope the problem to - dates and times formatted in Bookmarks and History window in Firefox. The regression was introduced in Firefox 52 by bug 1301655. We replaced nsIScriptableDateFormat with Intl.DateTimeFormat API. The fix to that bug is to make Intl.DateTimeFormat aware of regional settings which is done via mozIntl.DateTimeFormat. The patch which will transition those two windows to use mozIntl.DateTimeFormat is awaiting review in bug 1354445. In particular, this bug has nothing to do with DateTimeFormat.cpp. The mess around multiple ways of formatting dates and times is slowly coming to an end with bug 1351427 making C++ DateTimeFormat act on par with mozIntl.DateTimeFormat and those two becoming the only ways to format dates in Gecko. All other methods will be deprecated. Now I need to figure out how and if we can fix it in 54 because we certainly can't backport all the work that went into mozIntl.DateTimeFormat, nor can we back out all the patches from 1301655. Maybe we can just fine-tune how we display the date in treeView.js so that it's not ambiguous.
Blocks: 1301655
No longer depends on: 1351427, 1354442, 1355307
:BenB: I'm almost 100% certain that this screenshot is not related to this bug. This bug is about History and Bookmarks view in Firefox which uses treeView.js. Your screenshot is from some other UI, which probably also switched from nsIScriptableDateFormat to Intl.DateTimeFormat in 52 (maybe caused by the same bug - bug 1301655), but it is not this bug. I expect that one of the bugs either for DateTimeFormat.cpp, or for replacing Intl.DateTimeFormat with mozIntl.DateTimeFormat will fix your issue too, but if you want to debug it further, please, file a separate bug.
zibi, we're talking past each other. I'm not talking about Bookmarks or History window, but the underlying APIs. They are used across the whole app. If the bug was only in Bookmarks, I wouldn't be here. This affects Firefox, but Thunderbird and Lightning as well. The date in the message list in Thunderbird is wrong, the times in the Lightning calendar view are wrong, and the dates in the Lightning event dialog are wrong, whereas the time is correct. And these are just the first that I saw within the first few seconds of using the apps. I didn't look further, because that's completely unusable for me and I went back to 52. > this bug has nothing to do with DateTimeFormat.cpp. Bug 1342753 definitely changed DateTimeFormat.cpp, and according to its description, made it now ignore OS date/time settings and use the UI language as basis. This is inherently wrong. That's what I am objecting to. And I think this is what caused all the regressions everywhere. Maybe other APIs changed as well, then they should be revisited as well. I don't think the right fix is to change the callers, because it's never correct to use the UI language for date formatting. But that's now the default behavior of various date APIs. That's the problem that needs fixing.
> I'm not talking about Bookmarks or History window, but the underlying APIs. They are used across the whole app. If the bug was only in Bookmarks, I wouldn't be here. This bug is about two UI windows in Firefox. They use one type of API, other UI's may use other APIs. > This affects Firefox, but Thunderbird and Lightning as well. No, this bug, and it's solution, will not affect Thunderbird or Lightining. > Bug 1342753 definitely changed DateTimeFormat.cpp, and according to its description, made it now ignore OS date/time settings and use the UI language as basis. This is inherently wrong. That's what I am objecting to. I understand that. And bug 1351427 fixes it for you. But this is not this bug. > And I think this is what caused all the regressions everywhere. Maybe other APIs changed as well, then they should be revisited as well. This is not helpful when you try to push for a fix you need that uses one API in a bug about another API. This bug has nothing to do with Tb/Lighting callers. File a separate bug please for that, or wait for Jorg to land the fix in bug 1351427.
This is the simplest patch I can imagine, and thus the safest, which should fix the regression.
Attachment #8856814 - Attachment is obsolete: true
Attached image fix-mix.PNG —
Mark, can you verify that this fix would help with the regression? The full fix is coming in 55, but this is easy enough that we could aim to backport it to 54 if you'll say it makes sense.
Attachment #8856823 - Flags: feedback?(markh)
(the top is of course the regression, the bottom is with the patch. The middle is Paint UI)
Comment on attachment 8856823 [details] fix-mix.PNG LGTM, and I verified the patch fixes the issue for me on Nightly. Thanks!
Attachment #8856823 - Flags: feedback?(markh) → feedback+
Zibi, I'm also getting lost in this bug. I see the original report was about the History in Firefox. But how do you propose to fix that one UI, without fixing all the others? It seems to be the common API that makes those decisions on what is shown (yeah, there are 2 APIs, the C++ one and the JS one). I also agree with BenB that this needs to be fixed globally. It is fine that you take the locale from the app locale, but if the OS is in a similar locale (e.g. the leading en- is the same), then the common API should respect and use the OS locale for dates/times. That should not get us back to before bug 1342753 as there the en-* and jp-* wouldn't match and you would use the app locale as you do after the bug. Of course, if also some settings of date formats can be used also on a jp-* OS (as Jorg's pictures in bug 1351427 seem to imply), then of course that would be great too. But I understand you wanted to prevent Japanese month names or delimiter characters to appear in en-US app. That is totally reasonable. So you now take month names according to app locale (English). But the order of the date elements can still be taken from the OS locale. If these 2 aspects are possible to separate. So if this is no the bug for implementing this, which one is? Also please update the bug title if this one is strictly about the Firefox bookmarks/history.
(In reply to :aceman from comment #43) > Zibi, I'm also getting lost in this bug. I see the original report was about > the History in Firefox. But how do you propose to fix that one UI, without > fixing all the others? That's the only place I can find where dates are shown as "dd/mm/yy" - if there are others we should consider doing similar things to them too (and possibly even revert back in 55 if the other bugs mentioned above makes that possible) > I also agree with BenB that this needs to be fixed globally. I think everyone agrees, but IIUC, the current state of the world is that will happen in 55. > So if this is no the bug for implementing this, which one is? > Also please update the bug title if this one is strictly about the Firefox > bookmarks/history. Yes, the title should probably reflect that, so done!
Summary: Dates are displayed in US format instead of using the current OS format → Dates are displayed in US format in the places treeview instead of using the current OS format
:aceman - there are two bugs that once landed, should fix it "globally" - bug 1351427 and bug 1354445. Tb uses mostly the C++ API so bug 1351427 addresses that.
Comment on attachment 8856821 [details] [diff] [review] simple patch for 54 Marco, while the full fix is coming in bug 1354445, I have this trivial patch for 54 (and maybe 53)?
Attachment #8856821 - Flags: review?(mak77)
> This bug is about two UI windows in Firefox. They use one type of API, other UI's may use other API Really, DateTimeFormatter.cpp is used only in that one window? Nothing else uses it, even indirectly? > No, this bug, and it's solution, will not affect Thunderbird or Lightining. So, what broke Thunderbird, then? Why did TB and Lightning regress in the first place? Which bug number caused that? I'd be happy to be corrected! > can you verify that this fix would help with the regression? I don't see how that can fix the issue. Before, we used the OS setting. Now, we use UI language. If you change "04" to "Apr", that doesn't make us follow OS settings, either. It may fix it for Mark, because his AU locale matches US locale with everything but month, but it doesn't fix the issue for others like German, which e.g. has 24-hour format.
> Really, DateTimeFormatter.cpp is used only in that one window? Nothing else uses it, even indirectly? DateTimeFormat.cpp is not related to this bug at all. > So, what broke Thunderbird, then? Why did TB and Lightning regress in the first place? Which bug number caused that? I believe that it was bug 1225696. > I don't see how that can fix the issue. Before, we used the OS setting. Now, we use UI language. That crosses the line. I'm sorry, but if you don't understand what's going on, stop claiming that you do. > It may fix it for Mark, because his AU locale matches US locale with everything but month, but it doesn't fix the issue for others like German, which e.g. has 24-hour format. Correct, and the bug you're commenting in has nothing to do with German or 24h format. Please, file a bug for your particular problem and we can discuss it there. The idea that all UIs use a single API and share the same root of the problem and the same solution is flawed. By trying to bring a C++ API regression into this bug (which is about JS code) you're making it harder for us to work on it. Please, stop.
I really don't have time to read through all the comments here. Generally we must distinguish JS dates and C++ dates. FF uses C++ dates *only* in certificate details and navigation history. TB uses C++ dates in the thread pane very prominently. Right now, JS dates visible in the UI and C++ dates ignore the OS settings. However, that will be fixed: For C++ dates in bug 1351427 which I'm working on and for JS dates in bug 1354445. For the latter, the groundwork, mozIntl.DateTimeFormat is already implemented. Backing out bug 1342753 would be wrong. The idea is to respect OS settings as much as possible. So for an app version of en-US both FF and TB will respect any choice of en-* format/user locale and its specifically set OS format patterns. So an en-US app will fully respect en-AU settings. On the other hand it will not respect a user choice of de-DE since that makes on sense in. If it did, you'd end up with either |Date added: 1. März 2017| or if you used English, since after all the app is in English, |Date added: 1. March 2017|. Both these are an ugly mix which should be avoided. On a personal level, at first, I was very sceptical about what Zibi is doing since it's been a very bumpy ride, especially for Thunderbird. However, Zibi knows what he's doing, so cooperating with him is the way to go, not jumping in an demanding backouts at 4 AM at night with nonsensical comments like comment #32: "As such, bug 1351427 must be backed out to restore correct behavior." - No, bug 1351427 must *land*!!
> The idea is to respect OS settings as much as possible. OK. That's good. This is important. > On the other hand it will not respect a user choice of de-DE Sorry, I don't follow. Are you saying that for German users, you will now ignore the OS date/time setting? Even though we have used the OS setting for the last decade? This is particularly important for non-English locales. As you well know (you're German yourself), we write "1.4.2017, 19:00", and not "Apr 1, 2017, 7 PM". Even if a German uses an English build (e.g. because he uses a nightly, or because he prefers English, or whatever other reason), he does not want to use "7 PM" or "Apr 1, 2017". He will always want to have the German date/time formatting used. If that happens to use English strings, e.g. "Thursday, 1.4.2017, 19:00" (or, worst case, "1. March 2017"), e.g. German formatting with strings from the English locale, that's fine. This is much much better than using English notation like "1/4/2017 7 PM" or worse yet "4/1/2017 7 PM" on a German machine. Both are wrong for a German, even if it's an English build. It is very disturbing for me to see English date/time formatting.
> nonsensical comments like comment #32: "As such, bug 1351427 must be backed out Indeed, this made no sense at all, because I got the wrong bug number. Please ignore that :). All I'm saying is that we need to follow OS date/time settings.
User Story: (updated)
(In reply to Ben Bucksch (:BenB) from comment #50) > > On the other hand it will not respect a user choice of de-DE > Sorry, I don't follow. Are you saying that for German users, you will now > ignore the OS date/time setting? > Even though we have used the OS setting for the last decade? Yes, for the last decade we had a terrible mix of formats and languages that Zibi is in the process of cleaning up. I think anyone who wants a completely localised experience *must* use a localised Nightly build. I find US formats quite terrible myself, that's why I'm using en-GB setting on my machine, which are currently also ignored, but we're in the process of fixing that. Note that en-GB is almost like German apart from the separators. I think we need to lose the idea of injecting German elements into an en-* app. In Thunderbird the result was when injecting German elements: On 11.04.2017 21:04, Bugzilla@Mozilla wrote: No, that's just not on since this is no consistently localised version. So repeating: Current state: On 04/11/2017 09:04 PM, Bugzilla@Mozilla wrote: - bad, en-US, en-GB ignores, will fix! Future state: On 11/04/2017 21:04, Bugzilla@Mozilla wrote: - using en-GB setting in an en-US Nightly. Won't do: On 11.04.2017 21:04, Bugzilla@Mozilla wrote: - mixed bag of formats. Localised version: Am 11.04.2017 um 21:04 schrieb Bugzilla@Mozilla: - working today. (In reply to Ben Bucksch (:BenB) from comment #51) > All I'm saying is that we need to follow OS date/time settings. Yes, but within reason. The overall appearance must be that of a properly localised app.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #46) > Marco, while the full fix is coming in bug 1354445, I have this trivial > patch for 54 (and maybe 53)? Sorry, in Italian we use to say "the therapy is worse than the sickness". This will generate a frankenstein situation where the date moves from a numeric format to an alphanumeric format, while the time stays 12 hours. It's maybe going to work for en-AU, unlikely for some other languages, where it's also not that common to use short month names. Then in 55 that will revert back again to the status quo. It will also take far more space in the treeview, we picked the numeric format on purpose. That means we are likely to get regression bugs filed for the change to the short format, and then we'll get them for going backwards, since the previous change may look legit to some user. At that point, I'd prefer staying with the regression for 53 and 54, even if it's horrible, it will appear clearly as a bug. I'd surely accept a workaround/hack, provided it restore things *as they were*, even just visually, but I'm not prone to take a patch that further changes and enlarges the date format to a third option. The impact for bookmarks and history is not as critical as it is for Thunderbird, nobody is going to lose appointments because he reads the wrong date on a bookmark or a past history entry. That said, I'll listen and evaluate Mark's motivations if he thinks we should take this workaround. But please, stop the unrelated discussion about Thunderbird/Lightning and forced backouts, this is the wrong place and I won't tolerate further on that. Looks like there are already better bugs where to discuss that, and if they don't exist you can file them.
I agree the bug isn't severe enough to try and convince Mak the risks he describes are worth taking.
And this is basically a dupe of bug 1343768. I'm duping this there because this bug contains lots of unrelated digressions that are not useful to actually fix the Library bug. That bug is clean and we can limit the discussion to the actual argument there. That bug is also tracked for various versions.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Attachment #8856821 - Flags: review?(mak77) → review-
> On 11.04.2017 21:04, Bugzilla@Mozilla wrote: That's the expected result. This is correct. This uses the English locale, with the German date/time format that I chose, and that I need. That's what Thunderbird has always done. And it's what I expect and what I need. Wrong would be: > On 11/04/2017 21:04, Bugzilla@Mozilla wrote: because a) it does not follow the date/time format I configured. b) it's ambiguous in the international context. An American would read "Nov 4", although it's "Apr 11". This is an absolute no-go. Wrong would be: > On 11.04.2017 21:04, Bugzilla@Mozilla schrieb: because it has German text, which my English recipients cannot read Firefox and Thunderbird have always used by OS settings for date/time formats. If you do not agree with using that, then this is a serious regression. The basic problem is that you are confusing UI language and date/time settings. They have nothing to do with each other. Just take a look at Windows settings, and it will be clear. You can set the UI language separately from the region (they are different concepts!), and even if you set the region, you can still customize the date/time format. It's important that we follow that. Also when a German person uses English builds.
(In reply to Ben Bucksch (:BenB) from comment #56) > > On 11.04.2017 21:04, Bugzilla@Mozilla wrote: > That's the expected result. This is correct. This uses the English locale, > with the German date/time format that I chose, and that I need. > That's what Thunderbird has always done. And it's what I expect and what I > need. I have bad news for you: This will not come back. It makes no sense to embed German strings into English text. This was exactly the bug you wanted backed out: Japanese date/time underneath the word "Last 7 days" (attachment 8841316 [details]). Please understand that a properly localised application *cannot* permit snippets in other languages sprinkled through it. When bug 1351427 lands, RSN, the en-US build of TB will obey OS settings for any en-* locale, but it will not use nor obey any de-* locale. On Windows I have the option to use 2017-04-11 even in en-US and even en-GB. Set your locale to en-GB and be done with this issue. No American customer will see the dots and think: Ah, dots, German date, so 11.04. means April and not November.
(In reply to Marco Bonardo [::mak] from comment #55) > And this is basically a dupe of bug 1343768. I'm duping this there + some cleaning
No longer blocks: 1301655
tracking-firefox53: - → ---
No longer depends on: 1354445
See Also: 1342753 →
> I have bad news for you: This will not come back. This is why this is marked "dogfood". US (or British) date/time formats are completely intolerable for me. They are very prominent and important everywhere in the UI, and I will not be able to see and read them everywhere. OTOH, builds that we developers from source code make have only en-US. Adding German locale is not trivial. That, in fact, because I'm a developer, and I need to communicate about the menu item and UI names with other developers, I need to use English UI. So, taken together, you just made it impossible for me to use Thunderbird. Before somebody says that I'm the exception: There are many people who use English builds, but are not American. I have yet to see a rationale for this. You've ignored my argument: > b) it's ambiguous in the international context. An American would read "Nov 4", although it's "Apr 11". That alone is a killer. > It makes no sense to embed German strings into English text. There is not a single German string in that text. There is the date/time formatting that I prefer. But no German text. More generally, all other applications on the user's desktop will follow the OS date/time settings. If Firefox and Thunderbird show a different date/time format, that is a bug. Why should one Windows app show 01.04.2017 and Firefox show 01/04/2017?
Since the patch from bug 1354445 just landed in central, :markh, can you confirm that your problem is fixed in tomorrow's nightly?
Flags: needinfo?(markh)
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #60) > Since the patch from bug 1354445 just landed in central, :markh, can you > confirm that your problem is fixed in tomorrow's nightly? Yep, WFM, thanks!
Flags: needinfo?(markh)
(In reply to Ben Bucksch (:BenB) from comment #59) > More generally, all other applications on the user's desktop will follow the > OS date/time settings. If Firefox and Thunderbird show a different date/time > format, that is a bug. Why should one Windows app show 01.04.2017 and > Firefox show 01/04/2017? You need to argue this with Zibi. In bug 1354445 he just made it so that FF will use the app locale for all its dates/times in the UI, and will take "same language" OS patterns into account, so for an en-US version, the Australian or UK user can get en-AU or en-GB formats, but not de-DE formats. Bug 1351427 will make is so for the C++ times you see in TB in the thread pane. At best, there could be an option to 100% obey the OS settings. There is after all pref intl.locale.matchOS and I never understood that this is for (although I've asked: bug 1346616 comment #2). Zibi? Marco, sorry about the ongoing discussion, just un-CC yourself, the FF issues are fixed as far as reported here.
Flags: needinfo?(gandalf)
> At best, there could be an option to 100% obey the OS settings It's a dead end. Mixing date/time pattern/formattings/translations across locales is always going to lead us astray. Take an Arabic Windows (RTL, eastern arabic numerals) with English Firefox (LTR, western arabic numerals) and tell me how should the phrase "The certificate expires on Tuesday, January 5th 2016" should be formatted. > There is after all pref intl.locale.matchOS and I never understood that this is for (although I've asked: bug 1346616 comment #2). Zibi? It's a settings used to instruct the browser to attempt to match OS locale when negotiating languages. If your app has language resources for the OS locale, the app will use it. It's currently used in Firefox for Android and I plan to make it work with other Gecko apps (with ability to download additional language resources on fly - see bug 1325870 comment 0), but it's a massive effort and it'll take time to get there.
Flags: needinfo?(gandalf)
> > obey the OS settings > It's a dead end. Yet, somehow, Windows applications manage to do that since Windows 3.1 all the way up to Windows 10.
And not just Windows, but pretty much every OS, including GeoWorks (heh!), Mac OS 9, found it important enough to make an OS wide setting for this. http://www.guidebookgallery.org/screenshots/international Do you notice that for all of them, this setting is separate from the language? I wonder why that is....
Attachment #8856814 - Attachment is obsolete: false
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: