DESCRIPTION
These six tests are currently broken because the harness is miscalculating the start of DST by a week.
The root of the bug is in sta.js, around line 454. The variable 'dstStart' appears to be calculated correctly (on line 450), however this is then used to calculate 'DST_start_sunday', indicating whether daylight savings starts on the first or last Sunday in the month. DST 2012 in the US starts on the 11th of March, which is the second Sunday of the month, so 'first' is not an accurate description. :o) This is then used in DaylightSavingTA on line 665, which tries to determine the DST start date based on the misapprehension that DST starts on March 4th. This results in the UTC conversion being out on line 688.
------------------
TEST: TestCases/ch15/15.9/15.9.3/S15.9.3.1_A5_T1.js
SOURCE: http://hg.ecmascript.org/tests/test262/file/tip/test/suite/ch15/15.9/15.9.3/S15.9.3.1_A5_T1.js
TEST SUITE DATE: 2012-02-29
PLATFORM: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/536.3+ (KHTML, like Gecko) Version/5.1.3 Safari/534.53.10
ERROR: Error: Unexpected exception, "Test262 Error: #1: Incorrect value of Date" was thrown.
Unfortunately ConstructDate isn't really salvageable at this point. For this test to pass on compliant browsers anywhere in the world at any time, it needs to be aware of everything on http://www.webexhibits.org/daylightsaving/g.html which I suspect changes pretty frequently.
Consequently, I've taken the "easy" approach of making these tests valid by hardcoding the expected datetime's underlying value instead of relying on ConstructDate to do this. The change is in Hg, but not yet on the live website.
From Paul Ruizendaal
https://mail.mozilla.org/pipermail/test262-discuss/2012-September/000125.html
The fix hardcodes number values for California Summer time (i.e. 8 hours west of UTC). This is not very useful outside the PST time zone, and even not useful inside that zone in Winter, as the tests will fail.
Suggesting that the tests are rewritten like:
new Date(1970, 0).valueOf()-Date.prototype.getTimezoneOffset()*60000 === 0
etc.
Although the tests will not test the absolute time value, it will test that the parameters are handled correctly on a relative basis. A single test with ample comment could be added to test the absolute return value for a specific date (e.g. the epoch) and only that test would then fail in other timezones than PST (or more pc: UTC).
Another option would be to reinstate the Sputnik logic, as that would seem to be usable in most parts of the world, most of the time (if I understand correctly, the bug referenced above only occurs during one week in March in the PST time zone).