Diferença de interpretação de data JS da ISO 8601 - IE / FF versus Chrome

Por que os mecanismos javascript do IE / FF e Chromediferem em como interpretar estaFormato de data (AAAA-MM-DDTHH: mm: ss.fff) sem o designador de fuso horário?

new Date("2015-02-18T15:43:57.803").getUTCHours()
Horas UTC

Cromada: 15
IE11 / FF: 21

Eu não entendo isso - é porque o Chrome assume que é local, enquanto o IE / FF assume que é UTC? Parece um bug do Chrome.

Curiosamente - anexar um "Z" ao final da string informa ao Chrome e ao IE / FF que a hora é UTC e que eles podem concordar. Alguém mais notou essa discrepância na implementação de javascript comDate?

new Date("2015-02-18T15:43:57.803Z").getUTCHours()
Horas UTC

Cromada: 15
IE11 / FF: 15

Em última análise - este é o resultado daserializador pronto para uso para a API da Web do ASP.NET, que eu pensei que usava JSON.NET, mas agora parece ser interno onde o JSON.NET usaIsoDateTimeConverter.

VerificandoGlobalConfiguration.Configuration.Formatters.JsonFormatter me diz que estamos usandoJsonMediaTypeFormatter. A API da Web não está usando o serializador JSON.NET pronto para uso?

Esse é um benefício para as pessoas da API da Web - pelo menos no ASP.NET MVC, tínhamos um formato de data consistente (embora proprietário -/ Data (número de ticks) /) através doJavascriptSerializer

questionAnswers(2)

yourAnswerToTheQuestion