Closed Bug 943283 Opened 8 years ago Closed 5 years ago
Locale-specific JS number/date formatting should not make a trip through non-UTF encodings
59 bytes, text/x-review-board-request
XPCLocale.cpp assumes that locale-specific number/date formatting may go through a locale-dependent non-UTF encoding. This makes no sense in 2013 and gets in the way of removing nsIPlatformCharseet. Locale-specific number/date formatting should be possible using Unicode APIs only--possibly ICU.
We need to rewrite PRMJ_FormatTime so that it doesn't depend on CRT strftime which will return non-UTF-8 string on Windows, even in 2013.
An easiest solution would be using wcsftime on WIndows.
It seems that the right way to fix this in to fix bug 866344 and then remove the resulting dead code.
Depends on: 866344
After landing bug 1346674 and bug 1349470, we don't use NS_ILOCALE_DATE. So we can replace it with NS_CopyNativeToUnicode simply.
Comment on attachment 8851938 [details] Bug 943283 - Use NS_CopyNativeToUnicode instead of nsIUnicodeDecoder. https://reviewboard.mozilla.org/r/124192/#review126732 So according to the header (nsNativeCharsetUtils.h), NS_CopyNativeToUnicode "should only be used for converting *FILENAMES*...". However, in practice I think it's fine here, given the very limited scope where it's used.
Attachment #8851938 - Flags: review?(jfkthame) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/35caf320cf70 Use NS_CopyNativeToUnicode instead of nsIUnicodeDecoder. r=jfkthame
sorry had to back this out for build bustage like https://treeherder.mozilla.org/logviewer.html#?job_id=87140618&repo=autoland&lineNumber=14358 https://hg.mozilla.org/integration/autoland/rev/a9d7ba18975f
I should remove unused rv.
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/8c24ffa3f69e Use NS_CopyNativeToUnicode instead of nsIUnicodeDecoder. r=jfkthame
You need to log in before you can comment on or make changes to this bug.