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

RESOLVED DUPLICATE of bug 224703

Status

()

P3
normal
RESOLVED DUPLICATE of bug 224703
17 years ago
15 years ago

People

(Reporter: ji, Unassigned)

Tracking

({intl})

Trunk
All
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
Build: 03/14 

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

Comment 1

17 years ago
Created attachment 74162 [details]
This page doesn't show me the date correctly on my Simplified Chinese Windows XP
(Reporter)

Comment 2

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

Updated

17 years ago
Keywords: intl
QA Contact: ruixu → teruko
(Reporter)

Comment 3

17 years ago
Created attachment 74196 [details]
A screenshot

Comment 4

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

Comment 5

17 years ago
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.
Assignee: yokoyama → rogerl
Component: Internationalization → JavaScript Engine
Priority: -- → P3
QA Contact: teruko → pschwartau

Comment 6

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

If this is somehow a problem in JS Engine string handling,
please reassign back; thanks -
Assignee: rogerl → jst
Component: JavaScript Engine → DOM Level 0
QA Contact: pschwartau → desale

Comment 7

17 years ago
ftang:  The relevant code is in nsHTMLDocument::StartDocumentLoad(). You'll see
lots of string fu and conversion going on in there.
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
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

15 years ago
this is a dupe of 224703. i'm not sure which one to make a dupe of which. the
latter has a patch. 
You dup to the bug that's closer to being fixed.  ;)

*** This bug has been marked as a duplicate of 224703 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.