Re: Test S15.9.3.1_A5_T1 … T6

Norbert Lindenberg ecmascript at
Sun Sep 30 11:36:30 PDT 2012

Hi Paul,

Thanks for the comments! I agree that test262 has to run anywhere on planet Earth and can't hardcode values that only work in particular time zones.

Would you mind reopening the bug and adding your comments? That's probably the best way to ensure that this will get fixed eventually.


On Sep 28, 2012, at 15:51 , Paul Ruizendaal wrote:

> See also:
> 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).
> Paul
> _______________________________________________
> test262-discuss mailing list
> test262-discuss at

More information about the test262-discuss mailing list