Why do IE/FF and Chrome javascript engines differ on how to interpret this Date format (YYYY-MM-DDTHH:mm:ss.fff) without the timezone designator?
new Date("2015-02-18T15:43:57.803").getUTCHours()
Chrome: 15
IE11/FF: 21
I don't understand this - is it because Chrome assumes it's local whereas IE/FF assume it's UTC? This seems like a Chrome bug.
Interestingly - appending a "Z" to the end of the string tells both Chrome and IE/FF that the time is UTC and they can agree. Has anyone else noticed this javascript implementation discrepancy with Date?
new Date("2015-02-18T15:43:57.803Z").getUTCHours()
Chrome: 15
IE11/FF: 15
Ultimately - this is the result of the out-of-box serializer for ASP.NET Web API, which I thought used JSON.NET, but now appears to be internal where JSON.NET uses IsoDateTimeConverter.
Checking GlobalConfiguration.Configuration.Formatters.JsonFormatter tells me we're using JsonMediaTypeFormatter. Is Web API not using JSON.NET serializer out of the box?
This is a boon for Web API people - at least back in ASP.NET MVC we had a consistent date format (albeit proprietary - /Date(number of ticks)/) via the JavascriptSerializer
ES5 says that ISO 8601 format dates without a time zone should be treated as local(that interpretation has since been revised), but the ed. 6 draft says to treat them as UTC. Some script engines have implemented ed. 6, some ES5 and the rest neither.
The ed. 6 (and later) aren't consistent with the ISO 8601 specification.
The bottom line is don't use Date.parse (or pass strings to the Date constructor), manually parse date strings.