Angular.js: Модульные тесты терпят неудачу при запуске в Австралии

Возможно, нам следует добавить информацию о геолокации в запросы на вытягивание?

Я получаю аналогичную трассировку стека, когда запускаю тесты в Австралии:

(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ɹɥɔ

(со всей серьезностью, я поручил проблему себе и посмотрю на нее)

Я готов разобраться с этим лично, если поездка в Австралию обойдется мне в расходы :)

Та же проблема в Новой Зеландии.

Я не совсем понимаю, почему это так. Макет TzDate специально создан, чтобы не зависеть от часовых поясов.

Мы вычисляем смещение на основе ваших локальных настроек, а затем настраиваем дату, чтобы она была одинаковой для всех часовых поясов. См. Https://github.com/angular/angular.js/blob/547871e779f7a1e340c03296405735415764a0e8/src/ngMock/angular-mocks.js#L647 -L649

Я не понимаю, почему это нормально работает во всех часовых поясах, кроме Австралии и Новой Зеландии. Любые идеи?

@IgorMinar привет из будущего! Учитывая отключение на один, это просто проблема с летним временем (тесты пройдут, если я перееду в Брисбен, где они не практикуют летнее время). Спасибо за указатель, это была полезная подсказка. Я составлю пул-реквест.

На самом деле, при дальнейшем исследовании это не похоже на ошибку в тестах angular - возможно, это внутренняя проблема. Летнее время началось в Австралии в 1971 году, поэтому эпоха UNIX пришлась на 10:00 UTC + 10 1 января 1970 года.

Однако в тестах, использующих отрицательное смещение, как в этих, дает часовой пояс как +11 вместо +10. Это также можно увидеть в узле:

$ 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)

Результаты, кажется, сильно различаются в условиях, которые я не могу контролировать - Safari ошибается даже для новой даты (0), а некоторые условия, которые я не могу воспроизвести, имеют некоторые вкладки Chrome (но не новые, как в карме), делающие это правильно .

Есть обходной путь: изменить тесты для преобразования дат, которые не станут отрицательными. Это немного путаница, но, похоже, не делает тесты недействительными - надеюсь, это приемлемо?

Я считаю, что это связано с ES5 15.9.1.8 (https://es5.github.io/#x15.9.1.8).

«Реализация ECMAScript не должна пытаться определить, было ли точное время подвержено переходу на летнее время, а просто действовало бы летнее время, если бы в то время использовался текущий алгоритм перехода на летнее время. Это позволяет избежать таких осложнений, как с учетом лет, в которые в данном регионе круглый год соблюдалось летнее время.

Если среда хоста предоставляет функциональные возможности для определения летнего времени, реализация ECMAScript может отображать рассматриваемый год в эквивалентный год (тот же високосный год и тот же день начальной недели для года), для которого среда хоста предоставляет информация о переходе на летнее время. Единственное ограничение - все равнозначные годы должны давать одинаковый результат ".

Различные движки JS обрабатывают даты <1970 по-разному, когда дело доходит до настройки местного часового пояса. Некоторые двигатели сопоставляют <1970 г. с более современными годами, что объясняет, почему вы видите дату перехода на летнее время, хотя в Австралии в то время летнее время не соблюдалось.

См .: https://bugzilla.mozilla.org/show_bug.cgi?id=351066#c20 и https://bugzilla.mozilla.org/show_bug.cgi?id=1029923

+1

Лол (извините)

Пришел сюда с HN.YC. Это смешно! : D лол

+1 - Лучший отчет об ошибке!

+1 Австралия зациклила дайджест.

Кажется, это проблема со спецификацией, очевидно, вопрос в том, как это должно быть исправлено - поскольку в спецификации ECMAscript указано, что сегодня DST следует применять к прошлым годам, в то время как другие языки программирования, и особенно пользователи, ожидают другого поведения.

Либо кто-то должен написать оболочку вокруг Date, которая правильно реализует предыдущие данные DST и устраняет, следовательно, проблему, либо необходимо найти другое решение. Я не знаю, что было бы предпочтительнее, но для пользователя текущее решение определенно сбивает с толку.