Closed Bug 47409 Opened 25 years ago Closed 25 years ago

JavaScript Date() returns unconverted OS string

Categories

(Core :: JavaScript Engine, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: nhottanscp, Assigned: mike+mozilla)

Details

(Whiteboard: [nsbeta3+])

Attachments

(2 files)

It is reproducible by JS code as below using Japanese OS. I will attach a screen shot later. <HTML> <HEAD> <SCRIPT language="JavaScript"> function test() { dateString= new Date(); alert(dateString); } </SCRIPT> </HEAD> <BODY> <form> <input type="button", value = "test", onClick="test()"> </form> </BODY> </HTML>
Attached image screen shot
Lines from jsdate.c. I think the OS string is not converted to unicode. You can get OS charset by using nsIPlatformCharset. 1524 /* get a timezone string from the OS to include as a 1525 comment. */ 1526 new_explode(date, &split, JS_TRUE); 1527 PRMJ_FormatTime(tzbuf, sizeof tzbuf, "(%Z) ", &split);
Keywords: nsbeta3
Assigning to mccabe -
Assignee: rogerl → mccabe
Hm. You've found an aspect of the design... Because it has to be cross-platform and an embeddable component, there wasn't any easy way to teach the JS engine about different languages. I needed to make the string returned by toString be always parseable by the js engine, so I relegated the OS's notion of how to print the timezone to a (parenthesized comment) - and added that GMT-0700 text. The text in the ()s is optional. I'd like to keep it whenever we can display something reasonable, though. Is there a way to: - Detect when it won't be reasonable (and not display it then) - Make the OS string print out properly (so we'd then see 'Wed Aug etc etc GMT-0700 ([japanese characters] 2000') - always only get the English version of the time zone. Suggestions requested.
Status: NEW → ASSIGNED
> - Make the OS string print out properly That is possible by converting the OS string to unicode. nsIPlatformCharset can be used to get a OS charset. > - always only get the English version of the time zone. I think this is also acceptable since other strings (e.g. 'Wed Aug ') are not localized anyway. Is there offical spec for this? BTW, I also see this bug using 4.x.
IE5 win32 always shows English only (e.g. "Fri Aug 4 13:18:43 PDT2000" on my WinNT JA).
There's no obvious way given the strftime API (which the JS date API shims in prmjtime.c call through to) to get an english-only string representation of the timezone. Also, using interfaces from the Monkey proper isn't a good option, as the JS engine is standalone code (C code!) that isn't tied to the browser. I think that leaves: - omitting the timezone comment altogether - detecting when it isn't reasonable and omitting it then. Would checking for high bits or non-alphanumeric ascii work?
I think we should have a better solution for this, to get a UNICODE timezone, but this looks reasonable for now. Marking nsbeta3+.
Whiteboard: [nsbeta3+]
Conservative fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Would the reporter be able to get the latest build and try it? If it is OK, please mark the bug as "Verified" Otherwise, you can "Reopen" Thank you -
Verified on win32 build id 2000081608. No time zone string is included under WinNT JA, time zone string is included under WinNT US.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: