User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+ Date.prototype.toLocaleString() returns '21 Май 2005 г. 14:32:52' for the day of May, 21th, 2005 when the Regional Options in Control Panel are set to 'Russian'. The date should be read as '21 мая 2005 г.'. Note lowercase letter for the month name and the different declensional ending. Reproducible: Always Steps to Reproduce: var d = new Date(1116711172); alert(d.toLocaleString()); Actual Results: 21 Май 2005 г. 14:32:52 Expected Results: 21 мая 2005 г. 14:32:52

The current implementation of toLocaleString ( ), http://lxr.mozilla.org/mozilla/source/js/src/jsdate.c#1789 , contains: return date_toLocaleHelper(cx, obj, argc, argv, rval, #if defined(_WIN32) && !defined(__MWERKS__) "%#c" #else "%c" #endif which effectively causes call to strftime from <time.h> using "%#c", not "%c" argument. Note that %c means "The preferred date and time representation for the current locale." Now that special treatment of windows appeared after the following commit: date: 1998/04/24 00:29:56; author: fur; state: Exp; lines: +160 -93 Initial checkin of JavaScript 1.3, migrated from JSFUN13_BRANCH in /m/src reposi tory Perhaps nowdays the standard %c works on Windows properly? Can anybody with Windows check this?

The patch removes special treatment of Windows in date_toLocaleString and date_toLocaleDateString so only ANSI C standard format strings are used. Anybody with Windows and MSVC dares to try it?

This is not limited to Russian. For Polish it's e.g. "kwiecien" vs "kwietnia", similar problems probably appears with other languages using genitive forms of month names in full dates.

This still reproduces with Firefox 3.6 Beta 4. Also, toLocaleDateString has the same problem. For what it is worth, nsIScriptableDateFormat with dateFormatLong returns the correct string, at least in Russian. > var datefmtsvc = Components.classes['@mozilla.org/intl/scriptabledateformat;1'] > .getService(Components.interfaces.nsIScriptableDateFormat); > var str = datefmtsvc.FormatDateTime('ru', > datefmtsvc.dateFormatLong, datefmtsvc.timeFormatSeconds, > 2005, 5, 21, 14, 32, 52); > // ==> '21 мая 2005 г. 14:32:52'

(In reply to comment #6) > The patch removes special treatment of Windows in date_toLocaleString and > date_toLocaleDateString so only ANSI C standard format strings are used. > Anybody with Windows and MSVC dares to try it? I am not trying to compile Firefox with this patch, but according to the documentation on the MSDN Library, http://msdn.microsoft.com/en-us/library/fe06s4ak.aspx "%c" uses the short representation and "%#c" uses the long representation on Windows. When the locale is set to Russian, strftime returns as follows: %c: "21.05.2005 14:32:52" (short form, seemingly correct) %#c: "21 Май 2005 г. 14:32:52" (long form, incorrect) I am not sure whether we should switch from "%#c" to "%c" because it probably changes the behavior in almost all locales.

In my opinion, Date.prototype.toLocaleDateString should behave in the same way as nsIScriptableDateFormat.FormatDate with the first argument set to the empty string and the second argument set to either dateFormatLong or dateFormatShort. Why do they behave differently? nsIScriptableDateFormat.FormatDate seems to use genitive month names correctly (see also comment #8).

No longer reproducible in current Firefox (39), probably fixed when Intl API was enabled. Resolving as WFM. Tests: new Date("2015-05-21T14:32:52").toLocaleString("ru") "21.05.2015, 14:32:52" new Date("2015-05-21T14:32:52").toLocaleString("ru", {year: "numeric", month: "short", day: "2-digit", hour: "2-digit", minute: "2-digit", second: "2-digit"}) "21 мая 2015 г., 14:32:52"