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 UTCCromada: 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 UTCCromada: 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