User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; da; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008062218 Minefield/3.1a1pre From http://mxr.mozilla.org/mozilla-central/source/intl/locale/idl/nsIScriptableDateFormat.idl The documentation say: "format date and time, locale is language country pair (e.g. en-US) or empty string for application default" On empty string it actually uses the OS default Doing a quick check through http://mxr.mozilla.org/mozilla-central/search?string=nsIScriptableDateFormat I could only find uses which expect the documented default (app default), and not the implemented default (os default) This prevents many dates and times in the Firefox UI from being properly localized. Reproducible: Always Steps to Reproduce: 1. Use different OS and app lokales, in my case: OS: Windows XP SP2 Danish app: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008062218 Minefield/3.1a1pre 2. Run this JavaScript: var dts = Components.classes["@mozilla.org/intl/scriptabledateformat;1"] .getService(Components.interfaces.nsIScriptableDateFormat); var now = new Date(); var s = dts.FormatDateTime("", dts.dateFormatLong, dts.timeFormatNoSeconds, now.getFullYear(), now.getMonth() + 1, now.getDate(), now.getHours(), now.getMinutes(), 0); alert(s); Actual Results: 22. juni 2008 20:06 Expected Results: Sunday, June 22, 2008 8:07 PM I used the following code to generate the expected result above: var dts = Components.classes["@mozilla.org/intl/scriptabledateformat;1"] .getService(Components.interfaces.nsIScriptableDateFormat); var now = new Date(); var s = dts.FormatDateTime("en-US", dts.dateFormatLong, dts.timeFormatNoSeconds, now.getFullYear(), now.getMonth() + 1, now.getDate(), now.getHours(), now.getMinutes(), 0); alert(s);

Comment on attachment 326329 [details] [diff] [review] Make nsScriptableDateFormat default to general.useragent.locale instead of unknown Does this fail gracefully (e.g. fall back to the system locale) when general.useragent.locale is a locale not supported by the OS? r=me if the answer is yes.

Comment on attachment 326329 [details] [diff] [review] Make nsScriptableDateFormat default to general.useragent.locale instead of unknown No. Setting general.useragent.locale to foobar made it return an empty string.

Comment on attachment 326329 [details] [diff] [review] Make nsScriptableDateFormat default to general.useragent.locale instead of unknown Update: if general.useragent.locale is on the form ab[-CD], some fallback method is used. If not on that form, an empty string is used. I guess we can expect general.useragent.locale to be on that form. (Tested on Windows)

not trying to be a jerk about this or anything, but can we somehow get an xpcshell unit test for this?

(In reply to comment #5) > not trying to be a jerk about this or anything, but can we somehow get an > xpcshell unit test for this? > Not sure. There could be some tests like these: nsIScriptableDateFormat.FormatDateTime("en-US", ...) = a string which could be a en-US date. nsIScriptableDateFormat.FormatDateTime("ab-CD", ...) = a string which could be a date in any language. This would test the fallback. I don't think that "default locale = ui locale" can be tested in a doable way.

(In reply to comment #4) > (From update of attachment 326329 [details] [diff] [review]) > Update: if general.useragent.locale is on the form ab[-CD], some fallback > method is used. If not on that form, an empty string is used. I guess we can > expect general.useragent.locale to be on that form. (Tested on Windows) I know of one possible exception to that: ja-JP-MAC. Can you test on other platforms too? If not, let me know and I'll do it (but not in the next 24 hours, I'm afraid)

(In reply to comment #7) > I know of one possible exception to that: ja-JP-MAC. That would fail. So would kok-IN. see: http://mxr.mozilla.org/mozilla-central/source/intl/locale/src/windows/nsIWin32LocaleImpl.cpp#375 nsIWin32LocaleImpl::ParseLocaleString only allows LL-CC-RR, which should be fixed. > Can you test on other > platforms too? If not, let me know and I'll do it (but not in the next 24 > hours, I'm afraid) I don't have a mac and and it would probably take some days for me to figure out how to build Mozilla on linux.

This patch makes the Windows parser accept locales not on the form LL-RR. It will accept locales such as kok-IN and ja-JP-mac. It will not return NS_OK when it fails (which broke the fallback mechanism).

Fix Norwegian and memory

Comment on attachment 327314 [details] [diff] [review] Windows locale parser Is this patch ready for review? Sorry to be annoying, but can you transfer the patch to bug 22310? You rock for fixing this longstanding bug!

Comment on attachment 326329 [details] [diff] [review] Make nsScriptableDateFormat default to general.useragent.locale instead of unknown This fixes the bug on Windows (together with the parsing patch) and doesn't seem to cause regressions on other platforms. We are going to need some similar locale parsing love for Linux and Mac, but this is a great start.

(In reply to comment #12) > doesn't > seem to cause regressions on other platforms. No, this caused regression on Mac, when application locale is "ja-JP-mac" (see Bug 472666), or when it's "da", "de", "fi" and so on because of Bug 472960. If Bug 22310 and Bug 472960 get fixed, these regressions are fixed. Requesting blocking for either - backing out this or - both Bug 22310 and Bug 472960 get fixed.

Sorry for spam, clearing requesting blocking on this, because this is already fixed bug. Nominating Bug 472666 instead.

Some bugs in nsIScriptableDateFormat has been found, which occurs when a locale other than the OS default is used. I think this bug should be backed out until the other bugs are fixed. What do you say, Simon? I wonder if it would be better to leave nsIScriptableDateFormat as it was before and make another more flexible interface on top like this: http://mxr.mozilla.org/comm-central/source/calendar/base/src/calDateTimeFormatter.js

This caused regression bug 472666, but it also seems that you're relying on the general.useragent.locale pref being set usefully, which is definitely not true for multi-locale builds such as linux distros. I recommend that this be backed out.

Backed out: http://hg.mozilla.org/mozilla-central/rev/242203a5a26b

Comment on attachment 326329 [details] [diff] [review] Make nsScriptableDateFormat default to general.useragent.locale instead of unknown requesting approval1.9.1 for backing out

Comment on attachment 326329 [details] [diff] [review] Make nsScriptableDateFormat default to general.useragent.locale instead of unknown a=me for backout

Backed out on 1.9.1: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b5d9ae3cdb2c

Is this a good change at all? There's no Firefox locale which is correct for me (en-au) so I use the obvious fallback of en-us. But if firefox would start using en-us date format it would be rather ridiculous, there's no way I can read that date format correctly. System locale is always correct (if only because on windows, it's not tied to language but location). At least when it comes to date ordering, this is important since 02/01/2009 means something completely different in different locales.

Thanks for backing this out! Should this bug be marked WONTFIX, as it inevitably causes bug #474160 (as well as a few others) with the current description? I'm not certain the whole concept of this bug makes any sense -- if you get something that you don't expect in the place of date and time, why not fix your settings in the operating system? Does it make any sense to favour those users who cannot configure their operating system, versus others who can and who do expect to get the date and time in the format they've specified? I don't see much reason for mozilla to provide yet another way to configure date and time -- that's the job of the operating system (or desktop environment).

(In reply to comment #16) > I wonder if it would be better to leave nsIScriptableDateFormat as it was > before and make another more flexible interface on top like this: > http://mxr.mozilla.org/comm-central/source/calendar/base/src/calDateTimeFormatter.js Perhaps we could have a separate interface for date output in application locale exclusively? This would be a double win: 1) we could be more flexible in terms of date formats (e.g. I don't think any OS can provide us dates in form "October 3" without a year, or pseudo-dates like "Yesterday" and this is often used), 2) localizations without OS support could display dates properly localized. Here's an excerpt from my [ bug 519958 comment 10 ]: What I'm looking forward is for a way to define quite a big set of available date formats in toolkit, and see them reused in all apps. For example, this could include: * very close dates like "today", "yesterday", "tomorrow", "the day before yesterday", "the day after tomorrow", * close dates like "October 1", * generic dates, long format, as in "October 1, 2009", * generic dates, short format, as in "10/01/2009", * (probably) same formats, but with time and/or weekday added, * standalone weekdays, * standalone month names, * the presentation of standalone years ('2009 m.' in Lithuanian), * probably something else... Important thing is that month names and/or weekdays should be translatable separately for each of those cases, or at least some differentiation should be agreed upon. E.g., for Lithuanian, standalone month names should be translated differently from those followed by a day, but other languages might have different requirements.

This is a deprecating interface. I am not the component owner, but... WONTFIX?

nsIScriptableDateFormat is removed by bug 1313625