Angular.js: Os testes de unidade falham quando executados na Austrália

Criado em 19 nov. 2013  ·  14Comentários  ·  Fonte: angular/angular.js

Estou recebendo o mesmo erro relatado neste comentário: https://github.com/angular/angular.js/pull/3474#issuecomment -23241136

Eu também estou na Austrália / Sydney.

Consegui pular --force , mas seria bom receber um atestado de saúde por contribuir!

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)
ngMock moderate investigation broken expected use bug

Comentários muito úteis

Recebo um rastreamento de pilha semelhante quando executo os testes na Austrália:

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

(com toda a seriedade, atribuí o problema a mim mesmo e irei dar uma olhada nele)

Todos 14 comentários

Talvez devêssemos adicionar informações de geolocalização para obter solicitações?

Recebo um rastreamento de pilha semelhante quando executo os testes na Austrália:

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

(com toda a seriedade, atribuí o problema a mim mesmo e irei dar uma olhada nele)

Estou disposto a lidar com isso pessoalmente se uma viagem para a Austrália puder ser considerada uma despesa para mim :)

O mesmo problema na Nova Zelândia.

Não entendo muito bem por que isso acontece. O mock TzDate é construído especificamente para ser independente de fuso horário.

Calculamos o deslocamento com base em suas configurações locais e, em seguida, ajustamos a data para que seja a mesma em todos os fusos horários. Veja: https://github.com/angular/angular.js/blob/547871e779f7a1e340c03296405735415764a0e8/src/ngMock/angular-mocks.js#L647 -L649

Não entendo por que isso funciona bem em todos os fusos horários, exceto Austrália e Nova Zelândia. Alguma ideia?

@IgorMinar olá do futuro! Desprezado por um, isso só parece ser um problema de horário de verão (os testes passam se eu me mudar para Brisbane, onde eles não praticam o horário de verão). Obrigado pela indicação, foi uma pista útil. Vou preparar um pedido de pull.

Na verdade, em uma investigação mais aprofundada, isso não parece um bug nos testes angulares - talvez um problema nativo. O DST começou na Austrália em 1971, então a época do UNIX foi às 10:00 UTC + 10, 01/01/70.

No entanto, nos testes, usando um deslocamento negativo como esses, dá um fuso horário de +11 em vez de +10. Isso também pode ser visto no nó:

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

Os resultados parecem variar muito sob condições que não posso controlar - o Safari dá errado até mesmo para a nova Data (0), e algumas condições que não consigo reproduzir têm algumas guias do Chrome (mas não as novas como no karma) fazendo certo .

Há uma solução alternativa: alterar os testes para converter datas que não se tornarão negativas. É um pouco confuso, mas não parece invalidar os testes - espero que seja aceitável?

Acredito que isso seja devido ao ES5 15.9.1.8 (https://es5.github.io/#x15.9.1.8).

"A implementação do ECMAScript não deve tentar determinar se a hora exata estava sujeita ao horário de verão, mas apenas se o horário de verão estaria em vigor se o algoritmo de horário de verão atual tivesse sido usado na época. Isso evita complicações como levando em consideração os anos em que o local observou o horário de verão durante todo o ano.

Se o ambiente host fornece funcionalidade para determinar o horário de verão, a implementação do ECMAScript é livre para mapear o ano em questão para um ano equivalente (mesmo ano bissexto e mesmo dia da semana inicial para o ano) para o qual o ambiente host fornece informações sobre o horário de verão. A única restrição é que todos os anos equivalentes devem produzir o mesmo resultado. "

Diferentes mecanismos JS lidam com datas <1970 de forma diferente quando se trata de ajuste de fuso horário local. Alguns mecanismos mapeiam de 1970 a anos mais modernos, o que explicaria por que você está vendo a data com o horário de verão aplicado, embora a Austrália não tenha observado o horário de verão então.

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

+1

Lol desculpa)

Vim aqui de HN.YC. Isso é engraçado! : D lol

+1 - Melhor relatório de bug de todos os tempos!

+1 Austrália teve resumo em loop.

Parece ser um problema com a especificação, obviamente, a questão é como ela deve ser corrigida - como a especificação ECMAscript afirma, o DST de hoje deve ser aplicado aos anos anteriores, enquanto outras linguagens de programação, especialmente usuários, esperam um comportamento diferente.

Alguém teria que escrever um wrapper em torno de Date que implementasse corretamente os dados de horário de verão anteriores e corrigisse o problema, ou uma solução diferente precisa ser encontrada. Não sei qual seria preferível, mas para um usuário, a solução atual é definitivamente confusa.

Esta página foi útil?
0 / 5 - 0 avaliações