So far this has only affected a company internal website that parse the datestring to get the timezone. Internet Explorer, Netscape and Mozilla all have different ways of reporting the timezone. I suggest adopting the Mozilla format, as that is closest to the rest of the output of Date().toString() Safari currently reports: Mon Aug 01 2005 15:21:19 GMT-0400 Mozilla (firefox) reports: Mon Aug 01 2005 15:21:22 GMT-0400 (EDT) It feels like you could use a lookup into KnownZone in formatTime() to accomplish this.
just updating OS to 10.4 and version to 412+ to highlight that this is also an issue on tiger... just in case things are being prioritised away from jaguar bugs :)
Created attachment 5404 [details] Makes JavaScriptCore match Mozilla Makes JavaScriptCore match Mozilla if the timezone is known.
Comment on attachment 5404 [details] Makes JavaScriptCore match Mozilla Moves KnownZones higher so that formatTime can find it, changes formatTime to make use of it.
from a checkout today... /Users/jpayne/src/webkit/JavaScriptCore/kjs/date_object.cpp: In function 'KJS::UString KJS::formatTime (const tm&)': /Users/jpayne/src/webkit/JavaScriptCore/kjs/date_object.cpp:245: warning: suggest parentheses around assignment used as truth value /Users/jpayne/src/webkit/JavaScriptCore/kjs/date_object.cpp:247: error: 'gmtOffset' was not declared in this scope /Users/jpayne/src/webkit/JavaScriptCore/kjs/date_object.cpp:263: error: name lookup of 'i' changed for new ISO 'for' scoping /Users/jpayne/src/webkit/JavaScriptCore/kjs/date_object.cpp:245: error: using obsolete binding at 'i' /Users/jpayne/src/webkit/JavaScriptCore/kjs/date_object.cpp:263: warning: format '%s' expects type 'char*', but argument 10 has type 'const KJS::KnownZone' ** BUILD FAILED **
Comment on attachment 5404 [details] Makes JavaScriptCore match Mozilla It seems strange to list the time zone only if it's one of the hardcoded "known time zones". On Mac OS X and many other Unix systems, the timezone() function can be used to get the time zone abbreviation. On Win32, the GetTimeZoneInformation() function can probably be used.
I agree with darin's suggestion. Please use a function that knows about more time zones. Also, please provide a test case for this, if it is not already covered by the JS tests. It may be tricky to write a layout test for this that is time zone independent.
Created attachment 9500 [details] First attempt When in utc mode, I just use tm_zone info here. This should be ok since localtime should set it up correctly. Unfortunately there seem to be no tests for this. I used http://sackheads.org/~jpayne/timestring.html to test manually, and it matches Mozilla. Let me know if any tests should be added or whether we can reuse existing tests. Cheers, Rob.
Comment on attachment 9500 [details] First attempt Looks fine to me, but doesn't this affect some of our tests? r=me if not
Hi Darin, (In reply to comment #8) > (From update of attachment 9500 [details] [edit]) > Looks fine to me, but doesn't this affect some of our tests? > > r=me if not bdash couldn't see any changed results. But we concluded, it may be best if someone in the PDC timezone checks it, as NZ timezone gives issues with some of the tests. Cheers, Rob.
This change broke the Windows buildbot.