When LC_TIME is set, for example, to ru_RU.KOI8-R, the dates in about:cache documents become unreadable. This is caused by PR_FormatTime (and consequentially PrintTimeString) returning a date string with non-ASCII symbols in it which then is just appended to the document "as-is".

I also filed bug 120403 asking for PR_FormatTime to return a Unicode string, but I have no idea whether it's better to change PR_FormatTime or to fix it for about:cache only. BTW, this bug makes it harder to debug when something (e.g. favicons) is not cached properly.

cc'ing gordon and darin

I'll take this.

perhaps about:cache needs to be served up with a <meta http-equiv="content-type" content="text/html; charset=UTF-8"> tag?? or is there a better way to describe the document charset?? (i confess that i know little of the HTML standard :-/)

Darin, simply adding a charset declaration to the page is insufficient. (I know that for sure since it can not do anything "View -> Character Coding" can not and that does not help me to view the page correctly). The problem here is exactly that the date appended to the document is *not* initially in Unicode. It's an 8-bit char string that contains non-ASCII symbols. Something implicitly converts it to Unicode and for some reason converts the non-ASCII symbols without consulting the locale settings - just assumes it is ISO-8859-1! So, when I view the page with "Character Coding" set to "ISO-8859-1" it does show me something, although not what I want to see (it shows me ISO-8859-1 symbols that have the same 8-bit code as the corresponding KOI8-R symbols), and when I set "Character Coding" to "KOI8-R", it just shows me question marks (since it has no idea how to show ISO-8859-1 symbols using KOI8-R fonts)... I do not know whether it's just the about:date that needs to be fixed, or if it worth trying to make sure that whatver does this implicit 8bit char -> Unicode conversion always uses the locale settings and not just ISO-8859-1...

I receive that page set as KOI8-R (guess Autodetection kicks in), but I see only question marks. But if I explicitly select KOI8-R, even though it is ticked already, then I do see it without problems. <?xml version="1.0" encoding="UTF-8"?> is this the problem? I think not, since about:cache is served as text/html and not text/xml or application/xhtml+xml, but then I don't know, maybe HTML parser looks at XML tags as well. I'm not sure, but I think it should be possible to set the stream encoding without resorting to HTML <meta> tags. same way HTTP's Content-Type: header does it. However that raises 2 issues: The XML header becomes invalid. What happens to more exotic locale encodings like asian and arabic? Will that screw up the actual English text? At the moment about:cache does not support different locales what so ever, it is English text hardcoded in C++. And the date representation looks like a freak accident here. I personally think that about:cache should either be localisable completely, or have no localisation at all. Localising it would need a complete rewrite. So I think the date should ignore locale settings and be returned in English UTF-8 as the document encoding says until someone gets around to localising the whole thing. Also bug 94081 is related to the issue.

Could actually just use PR_FormatTimeUSEnglish() instead of PR_FormatTime() But everybody knows US time representation sux, just ask folks at bug 94081. ;o) I'd rather see it represented the same way as in HTTP protocol [RFC1123] except in local timezone, not GMT.

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.

http://lxr.mozilla.org/mozilla/source/intl/locale/public/nsIDateTimeFormat.h This looks like the functions that we need to use instead of PR_FormatTime.

This would also require change of the buffer to nsString from nsCString for locale specific date formats. I think this should be done after buffer code clean up (see bug 101863).

Interesting, this WFM now (BuildID 2002100119 trunk)...

PR_* should not be used directly. Instead, the APIs in intl/locale should be used here.

I'll take a look.

This WFM in BuildID 2003102323 running on Fedora Core 1.

Marking WFM due to the last comment. Reopen if your opinion is different and you can reproduce this with a current build. Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7a) Gecko/20040202