Chrome interprets ISO time without Z as UTC; C# issue

Question

Run this jsfiddle: http://jsfiddle.net/E9gq9/7/ on Chrome, FF, and IE and you get:

Chrome:

Chrome http://images.devs-on.net/Image/vBTz86J0f4o8zlL3-Region.png

Firefox:

Firefox http://images.devs-on.net/Image/aNPxNPUpltyjVpSX-Region.png

IE:

IE http://images.devs-on.net/Image/WXLM5Ev1Viq4ecFq-Region.png

Safari:

Safari http://images.devs-on.net/Image/AEcyUouX04k2yIPo-Region.png

ISO 8601 does not appear to say how a string without a trailing Z should be interpreted.

Our server (ASP.NET MVC4) is pulling UTC times out of our database as DateTimes and simply stuffing them in JSON. As you can see because of this we are getting inconsistent results on the browser.

Should we just append Z to them on the server side?

Answer 1

Should we just append Z to them on the server side?

TL;DR Yes, you probably should.

Correct handling of dates and date/times without a timezone has, sadly, varied through the years — both in terms of specification and JavaScript engines adherence to the specification.

When this answer was originally written in 2013, the ES5 spec (the first to have a defined date/time format for JavaScript, which was meant to be a subset of ISO-8601) was clear: No timezone = UTC:

The value of an absent time zone offset is “Z”.

But that was at odds with ISO-8601, in which the absense of a timezone indicator means "local time." Some implementations never implemented ES5's meaning, sticking instead to ISO-8601.

In ES2015 (aka "ES6"), it was changed to match ISO-8601:

If the time zone offset is absent, the date-time is interpreted as a local time.

However, this caused incompatibility problems with existing code, particularly with date-only forms like 2018-07-01, so in ES2016 it was changed yet again:

When the time zone offset is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.

So new Date("2018-07-01") is parsed as UTC, but new Date("2018-07-01T00") is parsed as local time.

It's been consistent since, in ES2017 and in the upcoming ES2018; here's the link to the current editor's draft, which no longer has that exact text but still defines it the same way (though IMHO less clearly).

You can test your current browser here:

function test(val, expect) {
  var result = +val === +expect ? "Good" : "ERROR";
  console.log(val.toISOString(), expect.toISOString(), result);
}
test(new Date("2018-07-01"), new Date(Date.UTC(2018, 6, 1)));
test(new Date("2018-07-01T00:00:00"), new Date(2018, 6, 1));

Status as of September 2021:

• Modern versions of Firefox, Chrome, and Safari get this right, including iOS browsers (which all currently use Apple's JavaScriptCore JavaScript engine since Apple won't let them use their own if they do JIT)
• IE11 gets it right (interestingly)

Status as of April 2018:

• IE11 gets it right (interestingly)
• Firefox gets it right
• Chrome 65 (desktop, Android) gets it right
• Chrome 64 (iOS v11.3) gets the date/time form wrong (parses as UTC)
• iOS Safari in v11.3 gets the date/time form wrong (parses as UTC)

Oddly, I can't find an issue in the v8 issues list that's been fixed between v6.4 (the v8 in Chrome 64) and v6.5 (the v8 in Chrome 65); I can only find this issue which is still open, but which appears to have been fixed.