Angular.js: Unit-Tests schlagen in Australien fehl

Vielleicht sollten wir Geolokalisierungsinformationen hinzufügen, um Anfragen abzurufen?

Ich erhalte eine ähnliche Stapelverfolgung, wenn ich die Tests in Australien durchführe:

(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 aller Ernsthaftigkeit habe ich mir das Problem selbst zugewiesen und werde es mir ansehen.)

Ich bin bereit, dies persönlich zu erledigen, wenn eine Reise nach Australien für mich als Aufwand erfasst werden kann :)

Gleiches Problem in Neuseeland.

Ich verstehe nicht ganz, warum das so ist. Das TzDate-Modell wurde speziell für die Zeitzonenunabhängigkeit entwickelt.

Wir berechnen den Versatz basierend auf Ihren lokalen Einstellungen und passen das Datum dann so an, dass es in allen Zeitzonen gleich ist. Siehe: https://github.com/angular/angular.js/blob/547871e779f7a1e340c03296405735415764a0e8/src/ngMock/angular-mocks.js#L647 -L649

Ich verstehe nicht, warum dies in allen Zeitzonen außer in Australien und Neuseeland gut funktioniert. Irgendwelche Ideen?

@IgorMinar Hallo aus der Zukunft! Angesichts des Ausfalls scheint dies nur ein DST-Problem zu sein (die Tests bestehen, wenn ich nach Brisbane ziehe, wo sie keine DST üben). Danke für den Hinweis, das war ein hilfreicher Hinweis. Ich werde eine Pull-Anfrage zusammenstellen.

Tatsächlich sieht dies bei weiteren Untersuchungen nicht wie ein Fehler in den Winkeltests aus - vielleicht ein natives Problem. Die Sommerzeit begann 1971 in Australien, daher war die UNIX-Epoche um 10:00 UTC + 10, 1.1.70.

Bei den Tests mit einem negativen Offset wie diesen ergibt sich jedoch eine Zeitzone von +11 anstelle von +10. Dies kann auch im Knoten gesehen werden:

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

Die Ergebnisse scheinen unter Bedingungen, die ich nicht kontrollieren kann, stark zu variieren - Safari macht es sogar für ein neues Datum (0) falsch, und einige Bedingungen, die ich nicht reproduzieren kann, haben einige Chrome-Tabs (aber keine neuen wie im Karma), die es richtig machen .

Es gibt eine Problemumgehung: Ändern Sie die Tests, um Daten zu konvertieren, die nicht negativ werden. Es ist ein bisschen kludge, scheint aber die Tests nicht ungültig zu machen - hoffentlich ist das akzeptabel?

Ich glaube, das liegt an ES5 15.9.1.8 (https://es5.github.io/#x15.9.1.8).

"Bei der Implementierung von ECMAScript sollte nicht versucht werden, festzustellen, ob die genaue Zeit der Sommerzeit unterliegt, sondern nur, ob die Sommerzeit wirksam gewesen wäre, wenn zu diesem Zeitpunkt der aktuelle Algorithmus für die Sommerzeit verwendet worden wäre. Dies vermeidet Komplikationen wie z unter Berücksichtigung der Jahre, in denen das Gebietsschema das ganze Jahr über Sommerzeit beobachtete.

Wenn die Host-Umgebung Funktionen zur Bestimmung der Sommerzeit bietet, kann die Implementierung von ECMAScript das betreffende Jahr einem entsprechenden Jahr (gleiches Schaltjahr und gleicher Startwochentag für das Jahr) zuordnen, das die Host-Umgebung bereitstellt Informationen zur Sommerzeit. Die einzige Einschränkung besteht darin, dass alle gleichwertigen Jahre das gleiche Ergebnis liefern sollten. "

Verschiedene JS-Engines behandeln Daten <1970 unterschiedlich, wenn es um die lokale Zeitzonenanpassung geht. Einige Motoren ordnen <1970 moderneren Jahren zu, was erklären würde, warum Sie das Datum sehen, an dem die Sommerzeit angewendet wurde, obwohl Australien damals die Sommerzeit nicht eingehalten hat.

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

+1

Lol sorry)

Kam hierher von HN.YC. Das ist lustig! : D lol

+1 - Bester Fehlerbericht aller Zeiten!

+1 Australien wurde verdaut.

Es scheint ein Problem mit der Spezifikation zu sein, offensichtlich ist die Frage, wie es behoben werden sollte - wie die ECMAscript-Spezifikation besagt, sollte die heutige Sommerzeit auf vergangene Jahre angewendet werden, während andere Programmiersprachen und insbesondere Benutzer ein anderes Verhalten erwarten.

Entweder müsste jemand einen Wrapper um Date schreiben, der frühere DST-Daten korrekt implementiert und daher das Problem behebt, oder es muss eine andere Lösung gefunden werden. Ich weiß nicht, was vorzuziehen wäre, aber für einen Benutzer ist die aktuelle Lösung definitiv verwirrend.