12070 2007-01-02 07:08:28 -0800 REGRESSION: KJS::getUTCOffset() caches UTC offset but ignores time zone changes 2007-06-24 12:04:45 -0700 1 1 1 Unclassified WebKit JavaScriptCore 420+ Mac OS X 10.4 RESOLVED FIXED Regression P1 Normal --- 1 ddkilzer ddkilzer kmccullough oldest_to_newest 37847 0 ddkilzer 2007-01-02 07:08:28 -0800 The KJS::getUTCOffset() method in JavaScriptCore/kjs/DateMath.cpp caches the UTC offset, but it never checks to see if the time zone has changed after caching the value (e.g., if a user opened the Date & Time system preference pane and changed their Mac's time zone). This doesn't seem to cause any issues (e.g., when running the test for Bug 12057), but I'd like to do further testing. This bug is a reminder to do that. 37555 1 ddkilzer 2007-01-02 20:14:52 -0800 Caching the UTC offset does create problems when changing the time zone through the Date & Time system preferences pane. It may be as simple as reporting the wrong time zone (reporting a daylight saving time zone when it's not daylight saving time) to reporting the wrong time zone offset (e.g., +1800 instead of -0600). Steps to reproduce: 1. Quit WebKit. 2. Set time zone to "London - England" (GMT +0000) in Date & Time pane. 3. Open WebKit. 4. Open this URL: javascript:alert(new Date()) 5. Set time zone to "Chicago - U.S.A." (CST -0600) in Date & Time pane. 6. Open this URL again: javascript:alert(new Date()) Expected results: Time zone should be reported as -0600 (CST) with the correct date and time. Actual results: Time zone is reported as +1800 (CDT) (or similar). 37537 2 ddkilzer 2007-01-02 20:22:19 -0800 (In reply to comment #1) > Caching the UTC offset does create problems when changing the time zone through > the Date & Time system preferences pane. It may be as simple as reporting the > wrong time zone (reporting a daylight saving time zone when it's not daylight > saving time) to reporting the wrong time zone offset (e.g., +1800 instead of > -0600). To be more specific, it may be as simple as the wrong time zone being reported (but the correct time), to reporting the wrong time zone offset, the wrong time zone (in DST when it shouldn't be) and a date in the future! 37530 3 ddkilzer 2007-01-02 20:27:10 -0800 Confirmed that this is a regression from shipping Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8N1037). Tested on locally-built debug build of WebKit r18541. There are basically two solutions: 1. Don't cache the UTC offset. 2. Cache the UTC offset and check for time zone changes to determine if it needs to be recalculated. 37220 4 12205 ddkilzer 2007-01-03 22:01:52 -0800 Created attachment 12205 Patch v1 If the user changes time zones without restarting a WebKit application like Safari, the cached UTC offset will cause JavaScript to report the wrong time zone and/or the wrong time. The simple solution is to stop caching the UTC offset and calculate it every time. That's what this patch does. Note that no performance testing has been done. 36975 5 ddkilzer 2007-01-04 21:57:26 -0800 Committed by Kevin McCullough in r18584. 6462 6 ddkilzer 2007-06-24 12:04:45 -0700 Mass removal of NeedsRadar keyword from my bugs that have already been RESOLVED. 12205 2007-01-03 22:01:52 -0800 2007-01-04 11:11:18 -0800 Patch v1 bug-12070-v1.diff text/plain 1737 ddkilzer SW5kZXg6IEphdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0 Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDE4NTc0KQorKysgSmF2YVNjcmlwdENvcmUvQ2hhbmdl TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTMgQEAKKzIwMDctMDEtMDMgIERhdmlkIEtp bHplciAgPGRka2lsemVyQHdlYmtpdC5vcmc+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZ IChPT1BTISkuCisKKyAgICAgICAgLSBmaXggaHR0cDovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1 Zy5jZ2k/aWQ9MTIwNzAKKyAgICAgICAgICBSRUdSRVNTSU9OOiBLSlM6OmdldFVUQ09mZnNldCgp IGNhY2hlcyBVVEMgb2Zmc2V0IGJ1dCBpZ25vcmVzIHRpbWUgem9uZSBjaGFuZ2VzCisKKyAgICAg ICAgKiBranMvRGF0ZU1hdGguY3BwOgorICAgICAgICAoS0pTOjpnZXRVVENPZmZzZXQpOiBEb24n dCBjYWNoZSBVVEMgb2Zmc2V0LgorCiAyMDA3LTAxLTAyICBEYXJpbiBBZGxlciAgPGRhcmluQGFw cGxlLmNvbT4KIAogICAgICAgICAtIG1pbm9yIHR3ZWFrIChob3BlIHRoaXMgZG9lc24ndCByZS1i cmVhayBXaW5kb3dzKQpJbmRleDogSmF2YVNjcmlwdENvcmUva2pzL0RhdGVNYXRoLmNwcAo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBKYXZhU2NyaXB0Q29yZS9ranMvRGF0ZU1hdGguY3BwCShyZXZpc2lvbiAxODU3 NCkKKysrIEphdmFTY3JpcHRDb3JlL2tqcy9EYXRlTWF0aC5jcHAJKHdvcmtpbmcgY29weSkKQEAg LTI5MywyMiArMjkzLDE3IEBAIGludCBlcXVpdmFsZW50WWVhckZvckRTVChpbnQgeWVhcikKICAq IE5PVCBpbmNsdWRpbmcgRFNULgogICovCiBkb3VibGUgZ2V0VVRDT2Zmc2V0KCkgewotICAgIHN0 YXRpYyBkb3VibGUgdXRjT2Zmc2V0OwotICAgIHN0YXRpYyBib29sIHV0Y09mZnNldEluaXRpYWxp emVkID0gZmFsc2U7Ci0gICAgaWYgKCF1dGNPZmZzZXRJbml0aWFsaXplZCkgewotICAgICAgICB0 bSBsb2NhbHQ7CisgICAgdG0gbG9jYWx0OwogCi0gICAgICAgIG1lbXNldCgmbG9jYWx0LCAwLCBz aXplb2YobG9jYWx0KSk7CisgICAgbWVtc2V0KCZsb2NhbHQsIDAsIHNpemVvZihsb2NhbHQpKTsK IAotICAgICAgICAvLyBnZXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGlzIHRpbWUgem9uZSBh bmQgVVRDIG9uIEphbiAwMSwgMjAwMCAxMjowMDowMCBBTQotICAgICAgICBsb2NhbHQudG1fbWRh eSA9IDE7Ci0gICAgICAgIGxvY2FsdC50bV95ZWFyID0gMTAwOwotICAgICAgICB1dGNPZmZzZXQg PSA5NDY2ODQ4MDAuMCAtIG1rdGltZSgmbG9jYWx0KTsKKyAgICAvLyBnZXQgdGhlIGRpZmZlcmVu Y2UgYmV0d2VlbiB0aGlzIHRpbWUgem9uZSBhbmQgVVRDIG9uIEphbiAwMSwgMjAwMCAxMjowMDow MCBBTQorICAgIGxvY2FsdC50bV9tZGF5ID0gMTsKKyAgICBsb2NhbHQudG1feWVhciA9IDEwMDsK KyAgICBkb3VibGUgdXRjT2Zmc2V0ID0gOTQ2Njg0ODAwLjAgLSBta3RpbWUoJmxvY2FsdCk7CiAK LSAgICAgICAgdXRjT2Zmc2V0ICo9IG1zUGVyU2Vjb25kOworICAgIHV0Y09mZnNldCAqPSBtc1Bl clNlY29uZDsKIAotICAgICAgICB1dGNPZmZzZXRJbml0aWFsaXplZCA9IHRydWU7Ci0gICAgfQog ICAgIHJldHVybiB1dGNPZmZzZXQ7CiB9CiAK