I built SpiderMonkey from source, ran the tests ($> tests/jstests.py build-release/js) and got the following result: [3001| 5| 0| 160] 100% ==========================================>| 71.5s REGRESSIONS js1_5/Regress/regress-58116.js js1_5/extensions/toLocaleFormat-01.js js1_5/extensions/toLocaleFormat-02.js ecma/Date/15.9.5.35-1.js ecma_3/Date/15.9.5.6.js They all seem related to locale or timezone or things like this. I'm going to investigate more and see if it's necessary to open separate bugs or if they can be all traced at the same source which, solved once will solve all regressions at once.

js> load('tests/shell.js') js> load('tests/js1_5/Regress/regress-58116.js') BUGNUMBER: 58116 STATUS: Compute Daylight savings time correctly regardless of year FAILED! Compute Daylight savings time correctly regardless of year Section 1 of test - 1970-07-1 : Expected value '-120', Actual value '-60' FAILED! Compute Daylight savings time correctly regardless of year Section 2 of test - 1965-07-1 : Expected value '-120', Actual value '-60' FAILED! Compute Daylight savings time correctly regardless of year Section 3 of test - 0000-07-1 : Expected value '-120', Actual value '-60' This code is testing Date.prototype.getTimezoneOffset. I don't feel qualified enough to understand whether the problem comes from getTimezoneOffset implementation or the test in my specific setting

js> load('tests/shell.js') js> load('tests/js1_5/extensions/toLocaleFormat-01.js') BUGNUMBER: 291494 STATUS: Date.prototype.toLocaleFormat extension FAILED! [reported from test()] Date.toLocaleFormat("%a") : Expected value 'Sun', Actual value 'dim.' FAILED! [reported from test()] Date.toLocaleFormat("%A") : Expected value 'Sunday', Actual value 'dimanche' FAILED! [reported from test()] Date.toLocaleFormat("%b") : Expected value 'Jun', Actual value 'juin' FAILED! [reported from test()] Date.toLocaleFormat("%B") : Expected value 'June', Actual value 'juin' PASSED! Date.toLocaleFormat("%d") PASSED! Date.toLocaleFormat(%H) FAILED! [reported from test()] Date.toLocaleFormat(%I) : Expected value '12', Actual value '0' PASSED! Date.toLocaleFormat("%j") PASSED! Date.toLocaleFormat("%m") PASSED! Date.toLocaleFormat("%M") FAILED! [reported from test()] Date.toLocaleFormat("%p") is AM or PM : Expected value 'true', Actual value 'false' (all the rest PASSES) The failures seem to be related to localization. Not sure what can be done about it.

js> load('tests/shell.js') js> load('tests/js1_5/extensions/toLocaleFormat-02.js') BUGNUMBER: 291494 STATUS: Date.prototype.toLocaleFormat extension (all PASSES except) FAILED! [reported from test()] Date.toLocaleFormat("%m/%d/%Y") == Date.toLocaleFormat("%x") : Expected value '06/05/2005', Actual value '05/06/2005' Joys of localizations :-)

js> load('tests/ecma/Date/15.9.5.35-1.js') BUGNUMBER: 291494 15.9.5.35-1 Date.prototype.setUTCMonth(mon [,date] ) tests/ecma/Date/15.9.5.35-1.js:100:26 ReferenceError: DateFromTime is not defined

js> load('tests/shell.js') js> load('tests/ecma_3/Date/15.9.5.6.js') 15.9.5.6 Date.prototype.toLocaleDateString() tests/ecma_3/Date/15.9.5.6.js:42:11 ReferenceError: now is not defined

The jit-test test suite had the same problem, a number of test failures if you are in another time zone. Bug 600522 fixed this, maybe we can do something similar for the jstest harness?

(In reply to David Bruant from comment #4) > js> load('tests/ecma/Date/15.9.5.35-1.js') > BUGNUMBER: 291494 > 15.9.5.35-1 Date.prototype.setUTCMonth(mon [,date] ) > tests/ecma/Date/15.9.5.35-1.js:100:26 ReferenceError: DateFromTime is not > defined I forgot to load ecma/shell.js One failure: FAILED! TDATE = new Date(0);(TDATE).setUTCMonth(5,4);TDATE.getHours() = 1 expected: 2 Indeed. Need a date format expert to decypher the problem...

(In reply to Jan de Mooij [:jandem] from comment #6) > The jit-test test suite had the same problem, a number of test failures if > you are in another time zone. Bug 600522 fixed this, maybe we can do > something similar for the jstest harness? In the Bug 600522 patch, I see the addition of a flag: + tz-pacific Always run test with the Pacific time zone (TZ=PST8PDT). That's a good way to make the tests pass, but potentially a good way to miss timezone related bugs in my opinion. I feel that if the tests are actual failure (which is yet to be determined), the test harness should be changed to test in different timezone/locale configurations.

Hmm... Just rm -Rf everthing, re-downloaded mc, re-built and I have 17 regressions now... [2989| 17| 0| 160] 100% ==========================================>| 69.9s REGRESSIONS js1_6/Regress/regress-372565.js js1_6/Regress/regress-355002.js js1_6/Regress/regress-350417.js js1_6/extensions/regress-455464-03.js js1_6/extensions/regress-455464-01.js js1_6/extensions/regress-352392.js js1_6/extensions/regress-455464-02.js js1_6/extensions/regress-475144.js js1_6/extensions/regress-565521.js js1_6/extensions/regress-465443.js js1_6/extensions/regress-472508.js js1_6/extensions/regress-455464-04.js js1_5/Regress/regress-58116.js js1_5/extensions/toLocaleFormat-01.js js1_5/extensions/toLocaleFormat-02.js ecma/Date/15.9.5.35-1.js ecma_3/Date/15.9.5.6.js FAIL

FYI on my laptop (which is from the UK) and with the time-zone set to CEST, I see the same five errors that were in the originally description when doing jstests.py on mozilla-inbound.

We have a bunch of bugs on file for this: https://bugzilla.mozilla.org/buglist.cgi?short_desc=test%20timezone&classification=Components&query_format=advanced&short_desc_type=allwordssubstr&component=JavaScript%20Engine I would dupe this one, but I don't know on which of the others. :/ And yes: it's annoying

I think bug 1089745 and bug 1123053 should have fixed this. At least it works for me now.

I can't get to building SpiderMonkey following the steps right now https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Build_Documentation But I guess if that works on your end with a non-US machine, this bug ca be considered fixed.

Works fine on my machine, in French timezone. Feel free to reopen if that's not the case.