Unit tests fail when run in Australia

[brettporter]

I'm receiving the same error reported in this comment: #3474 (comment)

I'm also in Australia/Sydney.

I was able to skip with --force, but it'd be good to get a clean bill of health for contributing!

Chrome 31.0.1650 (Mac OS X 10.9.0) ngMock TzDate should fake getHours method FAILED
    Expected 4 to be 3.
    Error: Expected 4 to be 3.
        at null.<anonymous> (/Users/brett/scm/github/angular.js/test/ngMock/angular-mocksSpec.js:60:29)
    Expected 1 to be 0.
    Error: Expected 1 to be 0.
        at null.<anonymous> (/Users/brett/scm/github/angular.js/test/ngMock/angular-mocksSpec.js:64:29)
    Expected 22 to match 21.
    Error: Expected 22 to match 21.
        at null.<anonymous> (/Users/brett/scm/github/angular.js/test/ngMock/angular-mocksSpec.js:68:29)

[wizardwerdna]

Perhaps we should add geolocation information to pull requests?

[btford]

I get a similar stacktrace when I run the tests in Australia:

(92:86:sɾ˙ɔǝdssʞɔoɯ-ɹɐlnƃuɐ/ʞɔoɯƃu/ʇsǝʇ/sɾ˙ɹɐlnƃuɐ/qnɥʇıƃ/ɯɔs/ʇʇǝɹq/sɹǝsn/) <snoɯʎuouɐ>˙llnu ʇɐ        
˙12 ɥɔʇɐɯ oʇ 22 pǝʇɔǝdxǝ :ɹoɹɹǝ    
˙12 ɥɔʇɐɯ oʇ 22 pǝʇɔǝdxǝ    
(92:46:sɾ˙ɔǝdssʞɔoɯ-ɹɐlnƃuɐ/ʞɔoɯƃu/ʇsǝʇ/sɾ˙ɹɐlnƃuɐ/qnɥʇıƃ/ɯɔs/ʇʇǝɹq/sɹǝsn/) <snoɯʎuouɐ>˙llnu ʇɐ        
˙0 ǝq oʇ 1 pǝʇɔǝdxǝ :ɹoɹɹǝ    
˙0 ǝq oʇ 1 pǝʇɔǝdxǝ    
(92:06:sɾ˙ɔǝdssʞɔoɯ-ɹɐlnƃuɐ/ʞɔoɯƃu/ʇsǝʇ/sɾ˙ɹɐlnƃuɐ/qnɥʇıƃ/ɯɔs/ʇʇǝɹq/sɹǝsn/) <snoɯʎuouɐ>˙llnu ʇɐ        
˙3 ǝq oʇ 4 pǝʇɔǝdxǝ :ɹoɹɹǝ    
˙3 ǝq oʇ 4 pǝʇɔǝdxǝ    
pǝlıɐɟ poɥʇǝɯ sɹnoɥʇǝƃ ǝʞɐɟ plnoɥs ǝʇɐpzʇ ʞɔoɯƃu (0˙9˙01 x so ɔɐɯ) 0561˙0˙13 ǝɯoɹɥɔ

(in all seriousness, i assigned the issue to myself and will take a look at it)

[matsko]

I'm willing to handle this in person if a trip to Australia can be expensed for me :)

[heymatthew]

Same issue in NZ.

[IgorMinar]

I don't quite understand why is this the case. The TzDate mock is specifically built to be time-zone agnostic.

We compute the offset based on your local settings and then adjust the date to be the same in all timezones. See:

angular.js/src/ngMock/angular-mocks.js

Lines 647 to 649 in 547871e

	var localOffset = new Date(timestamp).getTimezoneOffset();
	self.offsetDiff = localOffset*60*1000 - offset*1000*60*60;
	self.date = new Date(timestamp + self.offsetDiff);

I don't understand why this works fine in all timezones except for Australia and New Zealand. Any ideas?

[brettporter]

@IgorMinar hello from the future! Given the off by one, this just appears to be a DST issue (the tests pass if I were to move to Brisbane where they don't practice DST). Thanks for the pointer, that was a helpful clue. I'll put together a pull request.

[brettporter]

Actually, on further investigation, this doesn't look like a bug in the angular tests - perhaps a native problem. DST started in Australia in 1971, so the UNIX epoch was at 10:00 UTC+10, 1/1/70.

However, in the tests using a negative offset as these ones do gives a timezone as +11 instead of +10. This can be seen in node as well:

$ node
> new Date(0)
Thu Jan 01 1970 10:00:00 GMT+1000 (EST)
> new Date(-36000000)
Thu Jan 01 1970 01:00:00 GMT+1100 (EST)
> new Date(1970, 0, 1)
Thu Jan 01 1970 00:00:00 GMT+1100 (EST)
> new Date(1970, 0, 1, 1, 0, 0)
Thu Jan 01 1970 01:00:00 GMT+1100 (EST)

The results seem to vary wildly under conditions I can't control - Safari gets it wrong for even new Date(0), and some conditions I can't reproduce have some Chrome tabs (but not new ones as in karma) doing it right.

There's a workaround: to change the tests to convert dates that won't become negative. It's a bit of a kludge, but doesn't seem to invalidate the tests - hopefully that's acceptable?

[apaprocki]

I believe this is due to ES5 15.9.1.8 (https://es5.github.io/#x15.9.1.8).

"The implementation of ECMAScript should not try to determine whether the exact time was subject to daylight saving time, but just whether daylight saving time would have been in effect if the current daylight saving time algorithm had been used at the time. This avoids complications such as taking into account the years that the locale observed daylight saving time year round.

If the host environment provides functionality for determining daylight saving time, the implementation of ECMAScript is free to map the year in question to an equivalent year (same leap-year-ness and same starting week day for the year) for which the host environment provides daylight saving time information. The only restriction is that all equivalent years should produce the same result."

Different JS engines handle dates < 1970 differently when it comes to local timezone adjustment. Some engines map < 1970 to more modern years, which would explain why you are seeing the date have DST applied even though Australia didn't observe DST then.

See: https://bugzilla.mozilla.org/show_bug.cgi?id=351066#c20 and https://bugzilla.mozilla.org/show_bug.cgi?id=1029923

[hasokeric]

+1

[detaybey]

Lol (sorry)

[miglen]

Came here from HN.YC. This is funny! :D lol

[InfoSec812]

+1 - Best bug report ever!

[jspavlick]

+1 Australia got digest looped.

[justjanne]

It seems to be an issue with the specification, obviously, the question is, how it should be fixed – as the ECMAscript specification states todays DST should be applied to past years, while other programming languages, and especially users, expect a different behaviour.

Either someone would have to write a wrapper around Date that correctly implements previous DST data and fixes therefore the issue, or a different solution needs to be found. I don’t know which would be preferable, but to a user, the current solution is definitely confusing.