Angular.js: Les tests unitaires échouent lorsqu'ils sont exécutés en Australie

Peut-être devrions-nous ajouter des informations de géolocalisation aux pull requests?

J'obtiens un stacktrace similaire lorsque j'exécute les tests en Australie:

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

(sérieusement, je me suis attribué le problème et je vais y jeter un coup d'œil)

Je suis prêt à gérer cela en personne si un voyage en Australie peut me coûter cher :)

Même problème en NZ.

Je ne comprends pas très bien pourquoi c'est le cas. La maquette TzDate est spécialement conçue pour être indépendante du fuseau horaire.

Nous calculons le décalage en fonction de vos paramètres locaux, puis ajustons la date pour qu'elle soit la même dans tous les fuseaux horaires. Voir: https://github.com/angular/angular.js/blob/547871e779f7a1e340c03296405735415764a0e8/src/ngMock/angular-mocks.js#L647 -L649

Je ne comprends pas pourquoi cela fonctionne bien dans tous les fuseaux horaires, à l'exception de l'Australie et de la Nouvelle-Zélande. Des idées?

@IgorMinar bonjour du futur! Compte tenu de la situation, cela semble être un problème d'heure d'été (les tests réussissent si je devais déménager à Brisbane où ils ne pratiquent pas l'heure d'été). Merci pour le pointeur, c'était un indice utile. Je vais préparer une demande de tirage.

En fait, après une enquête plus approfondie, cela ne ressemble pas à un bogue dans les tests angulaires - peut-être un problème natif. L'heure d'été a commencé en Australie en 1971, donc l'époque UNIX était à 10h00 UTC + 10, 1/1/70.

Cependant, dans les tests utilisant un décalage négatif comme ceux-ci donnent un fuseau horaire comme +11 au lieu de +10. Cela peut également être vu dans node:

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

Les résultats semblent varier énormément dans des conditions que je ne peux pas contrôler - Safari se trompe même pour une nouvelle date (0), et certaines conditions que je ne peux pas reproduire ont des onglets Chrome (mais pas de nouveaux comme dans le karma) le faisant correctement .

Il existe une solution de contournement: modifier les tests pour convertir des dates qui ne deviendront pas négatives. C'est un peu un kludge, mais ne semble pas invalider les tests - j'espère que c'est acceptable?

Je pense que cela est dû à ES5 15.9.1.8 (https://es5.github.io/#x15.9.1.8).

"La mise en œuvre d'ECMAScript ne devrait pas essayer de déterminer si l'heure exacte était soumise à l'heure d'été, mais simplement si l'heure d'été aurait été en vigueur si l'algorithme d'heure d'été en cours avait été utilisé à ce moment-là. Cela évite des complications telles que en tenant compte des années pendant lesquelles le paramètre régional a observé l'heure d'été tout au long de l'année.

Si l'environnement hôte fournit des fonctionnalités pour déterminer l'heure d'été, l'implémentation d'ECMAScript est libre de mapper l'année en question sur une année équivalente (même année bissextile et même jour de semaine de début pour l'année) pour laquelle l'environnement hôte fournit informations d'heure d'été. La seule restriction est que toutes les années équivalentes doivent produire le même résultat. "

Différents moteurs JS traitent les dates <1970 différemment en ce qui concerne l'ajustement du fuseau horaire local. Certains moteurs mappent <1970 à des années plus modernes, ce qui expliquerait pourquoi vous voyez la date à laquelle l'heure d'été est appliquée même si l'Australie n'a pas observé l'heure d'été à ce moment-là.

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

+1

Lol désolé)

Je suis venu ici de HN.YC. C'est drôle! : D lol

+1 - Meilleur rapport de bogue de tous les temps!

+1 L'Australie a fait une boucle de résumé.

Cela semble être un problème avec la spécification, évidemment, la question est de savoir comment le résoudre - comme le stipule la spécification ECMAscript d'aujourd'hui, l'heure d'été devrait être appliquée aux années précédentes, tandis que d'autres langages de programmation, et en particulier les utilisateurs, s'attendent à un comportement différent.

Soit quelqu'un devrait écrire un wrapper autour de Date qui implémente correctement les données DST précédentes et corrige donc le problème, soit une solution différente doit être trouvée. Je ne sais pas ce qui serait préférable, mais pour un utilisateur, la solution actuelle est définitivement déroutante.