11157 2006-10-04 12:33:51 -0700 REGRESSION (r16780): Date conversion to local time gets the DST flag wrong for some dates 2006-10-11 12:47:25 -0700 1 1 1 Unclassified WebKit JavaScriptCore 420+ Mac OS X 10.4 RESOLVED LATER InRadar, Regression P1 Normal --- 1 mitz webkit-unassigned kmccullough oldest_to_newest 54416 0 mitz 2006-10-04 12:33:51 -0700 See bug 5514. The "compute DST flag based on a year which starts on the same day" doesn't work for all cases, so it shouldn't be used on platforms that support negative time_t, such as Mac. To see the regression, set your computer's time zone to New Zealand and open the attached test case, which is a variation on the test from bug 5514. It's weird that the original test didn't regress. It might point to a bug in the new implementation of the hack. 54417 1 10911 mitz 2006-10-04 12:34:21 -0700 Created attachment 10911 Test case 54494 2 kmccullough 2006-10-05 10:16:21 -0700 fixed with r16798. Will commit test case as a layout test 54499 3 mitz 2006-10-05 10:52:24 -0700 Still failing in TOT. 53929 4 10951 mitz 2006-10-06 12:07:40 -0700 Created attachment 10951 A test that fails in the Jerusalem timezone as of r16855 53503 5 kmccullough 2006-10-11 12:47:25 -0700 <rdar://4777813> There are several issues here: 1) Dates that shouldn't exist: for example April 25th 1982 2:30am Pacific because DST happens exactly at 2am, it skipps to 3am and 2:30am should never happen 2) Dates that happen twice: for example Oct 31, 1982 1:30am PST/PDT because DST makes 2am go back to 1am, the hour from 1am to 2am will happen twice 3) The History of DST: Some locations did not observer DST for some times (as seen by the command zdump) Here is a summary of our resolutions 3) According to the spec, history should not take into account what really happened but interpolate from a comparable year, where comparable years are judged by when Jan 1 happens and if the year is a leap year. This will only happen for dates that fall outside of the 1970-2038 range. if you fall out of that range then you are offset to a comparable year. This is consistent with what most browsers. 2) To address dates that happen twice, the standard behavior is to pick Standard Time (or the second time the time happens) 1) The final issue is what to do with times that should not have happened. Some browsers just show the time and some subtract an hour (e.g. 2am becomes 1am). What we think should happen is that an hour should be added (e.g. 2am becomes 3am). This has been added as a bug in Radar (number is at the top of this comment) 10911 2006-10-04 12:34:21 -0700 2006-10-06 12:09:16 -0700 Test case new-date-DST-pre-1970.html text/html 989 mitz PGh0bWw+CjxoZWFkPgo8c2NyaXB0PgpmdW5jdGlvbiBwcmludChtZXNzYWdlKSB7CiAgICB2YXIg cGFyYWdyYXBoID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgicCIpOwogICAgcGFyYWdyYXBoLmFw cGVuZENoaWxkKGRvY3VtZW50LmNyZWF0ZVRleHROb2RlKG1lc3NhZ2UpKTsKICAgIGRvY3VtZW50 LmdldEVsZW1lbnRCeUlkKCJjb25zb2xlIikuYXBwZW5kQ2hpbGQocGFyYWdyYXBoKTsKfQoKZnVu Y3Rpb24gdGVzdCgpIHsKICAgIGlmICh3aW5kb3cubGF5b3V0VGVzdENvbnRyb2xsZXIpIHsKICAg ICAgICBsYXlvdXRUZXN0Q29udHJvbGxlci5kdW1wQXNUZXh0KCk7CiAgICB9CgogICAgdmFyIGRh dGVzID0gWwogICAgICAgIG5ldyBEYXRlKDE5NjgsIDIsIDE3KSwgICAvLyBmYWlscyBpbiBOWgov LyAgICAgICAgbmV3IERhdGUoMTk2OSwgOCwgMSksICAgLy8gZmFpbHMgaW4gQ0VULCBBc2lhL0pl cnVzYWxlbQovLyAgICAgICAgbmV3IERhdGUoMTk2OSwgOSwgMjgpLCAgLy8gZmFpbHMgaW4gVVMv RWFzdGVybiwgTW91bnRhaW4sIFBhY2lmaWMsIENlbnRyYWwKICAgIF07CiAgICB3aGlsZSAoZCA9 IGRhdGVzLnNoaWZ0KCkpIHsKICAgICAgICBpZiAoZC5nZXRIb3VycygpICE9IDApIHsKICAgICAg ICAgICAgcHJpbnQoIkZBSUxFRDogIiArIGQpOwogICAgICAgICAgICBicmVhazsKICAgICAgICB9 CiAgICB9CiAgICBpZiAoIWQpCiAgICAgICAgcHJpbnQoIk5vdGhpbmcgZmFpbGVkLiBUaGlzIHRl c3RzIGNvdmVycyBvbmx5IHRoZSBOWiB0aW1lem9uZSEiKTsKfQo8L3NjcmlwdD4KPC9oZWFkPgo8 Ym9keSBvbmxvYWQ9InRlc3QoKTsiPgo8cD5UaGlzIHRlc3RzIHRoZSBEU1Qgc3RhdHVzIGluIGRh dGVzIGVhcmxpZXIgdGhhbiAxOTcwLTAxLTAxIDAwOjAwIFVUQy4gUmVnYXJkbGVzcyBvZiB5b3Vy IHRpbWUgem9uZSwgaXQgc2hvdWxkIG5vdCBmYWlsLjwvcD4KPGhyPgo8ZGl2IGlkPSdjb25zb2xl Jy8+CjwvYm9keT4KPC9odG1sPgo= 10951 2006-10-06 12:07:40 -0700 2006-10-06 12:07:40 -0700 A test that fails in the Jerusalem timezone as of r16855 Jerusalem-date-DST-pre-1970.html text/html 857 mitz PGh0bWw+CjxoZWFkPgo8c2NyaXB0PgpmdW5jdGlvbiBwcmludChtZXNzYWdlKSB7CiAgICB2YXIg cGFyYWdyYXBoID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgicCIpOwogICAgcGFyYWdyYXBoLmFw cGVuZENoaWxkKGRvY3VtZW50LmNyZWF0ZVRleHROb2RlKG1lc3NhZ2UpKTsKICAgIGRvY3VtZW50 LmdldEVsZW1lbnRCeUlkKCJjb25zb2xlIikuYXBwZW5kQ2hpbGQocGFyYWdyYXBoKTsKfQoKZnVu Y3Rpb24gdGVzdCgpIHsKICAgIGlmICh3aW5kb3cubGF5b3V0VGVzdENvbnRyb2xsZXIpIHsKICAg ICAgICBsYXlvdXRUZXN0Q29udHJvbGxlci5kdW1wQXNUZXh0KCk7CiAgICB9CgogICAgdmFyIGRh dGVzID0gWwogICAgICAgIG5ldyBEYXRlKDE5NjgsIDIsIDE1KSwgICAvLyBmYWlscyBpbiBBc2lh L0plcnVzYWxlbQogICAgXTsKICAgIHdoaWxlIChkID0gZGF0ZXMuc2hpZnQoKSkgewogICAgICAg IGlmIChkLmdldEhvdXJzKCkgIT0gMCkgewogICAgICAgICAgICBwcmludCgiRkFJTEVEOiAiICsg ZCk7CiAgICAgICAgICAgIGJyZWFrOwogICAgICAgIH0KICAgIH0KICAgIGlmICghZCkKICAgICAg ICBwcmludCgiTm90aGluZyBmYWlsZWQuIFRoaXMgdGVzdHMgY292ZXJzIG9ubHkgdGhlIEplcnVz YWxlbSB0aW1lem9uZSEiKTsKfQo8L3NjcmlwdD4KPC9oZWFkPgo8Ym9keSBvbmxvYWQ9InRlc3Qo KTsiPgo8cD5UaGlzIHRlc3RzIHRoZSBEU1Qgc3RhdHVzIGluIGRhdGVzIGVhcmxpZXIgdGhhbiAx OTcwLTAxLTAxIDAwOjAwIFVUQy4gUmVnYXJkbGVzcyBvZiB5b3VyIHRpbWUgem9uZSwgaXQgc2hv dWxkIG5vdCBmYWlsLjwvcD4KPGhyPgo8ZGl2IGlkPSdjb25zb2xlJy8+CjwvYm9keT4KPC9odG1s Pgo=