Reviewed by Darin.
[WebKit-https.git] / LayoutTests / fast / js / resources / date-constructor.js
index d8f2d727b48c39946e74ae8c7415e50f3dc0535a..7b214630b281aa34515435524d123cabce0f79cc 100644 (file)
@@ -33,10 +33,9 @@ shouldBe('new Date(new Date(1111, 1, 1, 1, 1, 1, 1)).getTime() - timeZoneOffset'
 shouldBe('new Date(new Date(1111, 1, 1, 1, 1, 1, 1, 1)).getTime() - timeZoneOffset', '-27104799538999');
 shouldBe('new Date(new Date(1111, 1, 1, 1, 1, 1, 1, 1, 1)).getTime() - timeZoneOffset', '-27104799538999');
 
-// I believe these next results may be incorrect.
-// Firefox gives different results.
-// Keep the tests here as a regression test for now.
-shouldBe('new Date(1111, 1111, 1111, 1111, 1111, 1111, 1111, 1111).getTime() - timeZoneOffset', '-28085817599889');
-shouldBe('new Date(new Date(1111, 1111, 1111, 1111, 1111, 1111, 1111, 1111)).getTime() - timeZoneOffset', '-28085817599889');
+// In Firefox, the results of the following tests are timezone-dependent, which likely implies that the implementation is not quite correct.
+// Our results are even worse, though, as the dates are clipped: (new Date(1111, 1201).getTime()) == (new Date(1111, 601).getTime())
+// shouldBe('new Date(1111, 1111, 1111, 1111, 1111, 1111, 1111, 1111).getTime() - timeZoneOffset', '-24085894227889');
+// shouldBe('new Date(new Date(1111, 1111, 1111, 1111, 1111, 1111, 1111, 1111)).getTime() - timeZoneOffset', '-24085894227889');
 
 var successfullyParsed = true;