Closed
Bug 47409
Opened 25 years ago
Closed 25 years ago
JavaScript Date() returns unconverted OS string
Categories
(Core :: JavaScript Engine, defect, P3)
Core
JavaScript Engine
Tracking
()
VERIFIED
FIXED
People
(Reporter: nhottanscp, Assigned: mike+mozilla)
Details
(Whiteboard: [nsbeta3+])
Attachments
(2 files)
8.42 KB,
image/jpeg
|
Details | |
1.76 KB,
patch
|
Details | Diff | Splinter Review |
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>
Reporter | ||
Comment 1•25 years ago
|
||
Reporter | ||
Comment 2•25 years ago
|
||
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);
Assignee | ||
Comment 4•25 years ago
|
||
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
Reporter | ||
Comment 5•25 years ago
|
||
> - 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.
Reporter | ||
Comment 6•25 years ago
|
||
IE5 win32 always shows English only (e.g. "Fri Aug 4 13:18:43 PDT2000" on my
WinNT JA).
Assignee | ||
Comment 7•25 years ago
|
||
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?
Assignee | ||
Comment 8•25 years ago
|
||
Comment 9•25 years ago
|
||
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+]
Assignee | ||
Comment 10•25 years ago
|
||
Conservative fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 11•25 years ago
|
||
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 -
Reporter | ||
Comment 12•25 years ago
|
||
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.
Description
•