このコメントで報告されているのと同じエラーが表示されます: //github.com/angular/angular.js/pull/3474#issuecomment -23241136
私もオーストラリア/シドニーにいます。
私は--force
でスキップすることができましたが、貢献するためのきれいな健康法案を手に入れるのは良いことです!
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)
おそらく、プルリクエストにジオロケーション情報を追加する必要がありますか?
オーストラリアでテストを実行すると、同様のスタックトレースが得られます。
(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 :
オーストラリアとニュージーランドを除くすべてのタイムゾーンでこれが正常に機能する理由がわかりません。 何か案は?
@IgorMinar未来からこんにちは! 1つずつオフになっていることを考えると、これはDSTの問題のように見えます(DSTを実践していないブリスベンに移動した場合、テストは合格です)。 ポインタをありがとう、それは役に立つ手がかりでした。 プルリクエストをまとめます。
実際、さらに調査すると、これは角度テストのバグのようには見えません-おそらくネイティブの問題です。 DSTは1971年にオーストラリアで開始されたため、UNIXエポックは10:00 UTC + 10、1 / 1/70でした。
ただし、これらのように負のオフセットを使用するテストでは、タイムゾーンが+10ではなく+11になります。 これはノードでも見ることができます:
$ 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は新しいDate(0)でも間違ってしまい、再現できないいくつかの条件では、いくつかのChromeタブ(カルマのように新しいタブではない)が正しく実行されます。
回避策があります。テストを変更して、負にならない日付を変換することです。 それは少し厄介ですが、テストを無効にするようには見えません-うまくいけばそれは許容できますか?
これはES515.9.1.8(https://es5.github.io/#x15.9.1.8)によるものだと思います。
「ECMAScriptの実装では、正確な時刻が夏時間の対象であるかどうかを判断するのではなく、現在の夏時間アルゴリズムがその時点で使用されていた場合に夏時間が有効であったかどうかを判断する必要があります。これにより、このような複雑さが回避されます。ロケールが一年中夏時間を観察した年を考慮に入れるように。
ホスト環境が夏時間を決定する機能を提供する場合、ECMAScriptの実装は、問題の年を、ホスト環境が提供する同等の年(同じうるう年と同じ開始曜日)に自由にマップできます。夏時間情報。 唯一の制限は、すべての同等の年が同じ結果を生み出すはずだということです。」
ローカルタイムゾーンの調整に関しては、JSエンジンが異なれば1970年未満の日付の処理も異なります。 一部のエンジンは1970年未満をより現代にマッピングします。これは、オーストラリアがDSTを監視していなかったにもかかわらず、日付がDSTに適用されていることを示している理由を説明しています。
https://bugzilla.mozilla.org/show_bug.cgi?id=351066#c20およびhttps://bugzilla.mozilla.org/show_bug.cgi?id=1029923を参照してください。
+1
笑(ごめんなさい)
HN.YCから来ました。 これは面白いです! :D lol
+ 1-史上最高のバグレポート!
+1オーストラリアはダイジェストがループしました。
ECMAscript仕様では、今日のDSTは過去数年間に適用する必要があると述べられていますが、他のプログラミング言語、特にユーザーは異なる動作を期待しているため、仕様に問題があるようです。
誰かが以前のDSTデータを正しく実装して問題を修正する、Dateのラッパーを作成する必要があるか、別の解決策を見つける必要があります。 どちらが望ましいかはわかりませんが、ユーザーにとって、現在のソリューションは間違いなく混乱を招きます。
最も参考になるコメント
オーストラリアでテストを実行すると、同様のスタックトレースが得られます。
(真剣に、私は自分自身に問題を割り当て、それを見ていきます)