131006 - JavaScript document.lastModified displays garbled date in multi-byte locale

Status: RESOLVED DUPLICATE of bug 224703

(Core :: DOM: Core & HTML, defect, P3)

Description

[ji]

Build: 03/14 

JavaScript document.lastModified doesn't show the system date correctly in
multi-byte locale.
Testcase to follow.

Comment 1

[ji]

Attachment: This page doesn't show me the date correctly on my Simplified Chinese Windows XP

Comment 2

[ji]

To see the problem, please download the file into local, and open it from navigator.

Comment 3

[ji]

Attachment: A screenshot

Comment 4

[Yuying Long]

I can reproduce it on linux 7.2 with JA locale, but WinXP-CN works fine.

Comment 5

[Frank Tang]

It looks like the JS code currently convert the lastModified date by using the
AssignWithConversion of string class instead of convert from ACP to Unicode by
using the MultibyteToWideChar on widow. 

cc nhotta, change the component to JavaScript
javascript group, please point out where is the code which format the date into
string and ask for our help (nhotta,yokoyama,shanjian,smontagu) to fix it

Looks like a P3 to me.

Comment 6

[Phil Schwartau]

The string |document.lastModified| is a DOM production, reassigning.

If this is somehow a problem in JS Engine string handling,
please reassign back; thanks -

Comment 7

[Håkan Waara]

ftang:  The relevant code is in nsHTMLDocument::StartDocumentLoad(). You'll see
lots of string fu and conversion going on in there.

Comment 8

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 9

[Boris Zbarsky [:bzbarsky]]

The code has moved.  Now there is the code in
nsDocument::RetrieveRelevantHeaders that gets the HTTP header and failing that
uses PR_FormatTime to format the file modification date and there is code in
nsDocument::GetLastModified that copies the date to UTF-16 (treating it as ASCII).

There are two issues here:

1)  What format can the HTTP header come in?  Will it always be ASCII?
2)  What does PR_FormatTime output?

It looks like #2 is "locale-specific" -- would it need to be converted via
NativeToUnicode?

I'd say that mLastModified should be UTF-8 and that RetrieveRelevantHeaders
should handle conversion to that encoding as needed....

Comment 10

[Jungshik Shin]

this is a dupe of 224703. i'm not sure which one to make a dupe of which. the
latter has a patch. 

Comment 11

[Boris Zbarsky [:bzbarsky]]

You dup to the bug that's closer to being fixed.  ;)

*** This bug has been marked as a duplicate of 224703 ***