Bug 68749 – new Date().toString() returns curious timezone information in Windows + Japanese Language

• Status: UNCONFIRMED
• Component: JavaScriptCore

[Yusuke Suzuki]

Created attachment 108575 [details]
use GetTimeZoneInformation and WideCharToMultiByte

strftime in Windows + Japanese language returns multibyte time zone value.

example:
"東京 (標準時)"

formatTime uses strftime and gets this as multibyte char. So in Windows + Japanese language, gets this as CP932 characters and new Date().toString() returns curious result.

I suggests using GetTimeZoneInformation, checking StandardName / DaylightName (this is wide characters), and converting it to UTF-8 by WideCharToMultiByte.

[Yusuke Suzuki]

Created attachment 108577 [details]
use String::fromUTF8

now, formatTime result value is UTF8. so convert to UTF16 and use it.

[Hajime Morrita]

Comment on attachment 108577 [details]
use String::fromUTF8

You need
- a test case (see LayoutTests/fast/js)
- to update ChangeLog files (You can use prepare-ChangeLog script to make a stub. See http://www.webkit.org/coding/contributing.html. I recommend you to use Tools/Scripts/webkit-patch script to upload the patch here. It cares some trivial stuff for you, like requesting review, checking coding style, etc.

By the way, could you refer the specification section which claims expected behavior?

[Yusuke Suzuki]

Thanks for your review.

>> - a test case (see LayoutTests/fast/js)

I don't know how should I write a test for this issue, because new Date().toString() output is different in each OS and language settings.

example:
MacOSX 10.7.1 + JST
"Sat Sep 24 2011 17:05:06 GMT+0900 (JST)"

Windows 7 + JST should be
"Sat Sep 24 2011 17:05:06 GMT+0900 (東京 (標準時))"

(not patched)
"Sat Sep 24 2011 17:05:06 GMT+0900 (  (W))"
* concatnated raw CP932 codes [40,147,140,139,158,32,40,149,87,143,128,142,158,41]

in addition to this, ECMA262 5.1 doesn't specify expected behavior.
I searched V8 cctests, sputniktests, es5conform, mjsunit, and test262, but no test found for this.
What do you think about?

>> By the way, could you refer the specification section which claims expected behavior?

ECMA262 5.1 specifies this format as "implementation-dependent" (section 15.9.5.2 / 15.9.5.4)
"This function returns a String value. The contents of the String are implementation-dependent, but are intended to represent the Date in the current time zone in a convenient, human-readable form."
http://es5.github.com/#x15.9.5.4

SpiderMonkey rejects timezone information when it includes non-ascii character.
http://hg.mozilla.org/tracemonkey/file/74b2b46fca7d/js/src/jsdate.cpp#l2195
in Windows + Japanese language, result is "Sat Sep 24 2011 17:05:06 GMT+0900"

V8 provides non-ascii timezone information.
http://code.google.com/p/v8/source/browse/trunk/src/platform-win32.cc#368
in Windows + Japanese language, result is "Sat Sep 24 2011 17:05:06 GMT+0900 (東京 (標準時))"

in this ruby-list thread, they concluded that getting ASCII timezone information in Windows + Japanese language is difficult.
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/24731

test262 (and sputniktests) doesn't check new Date().toString() output format (because of implementation-dependent)

So, I think that it is valid if timezone information is not provided, but for compatibility with older JSC, V8 method is good in this case.

[Hajime Morrita]

It looks you're stepping into complicated area...
CCing folks who know JSC well.

FYI: LayoutTests assume a specific locale. which is not JA_jp. (Maybe en_US.)