Date Time String Format: default time zone difference from ES5 not web-compatible

[ajklein]

In Chrome 46, we shipped a change to date formatting per ES2015 that a missing time zone should be treated as local time (where in ES5 it was treated as UTC). See https://code.google.com/p/chromium/issues/detail?id=543320 for details, in particular comment 5 (which lays out the exact difference).

Given the breakage, and that no other browsers seems to have shipped this change, it seems like the easiest thing to do would be to revert to the ES5 behavior. But I'm not sure what prompted the change in the first place, so it's hard to weigh such a change.

[anba]

But I'm not sure what prompted the change in the first place, so it's hard to weigh such a change.

It was changed to local time to match ISO-8601 (https://bugs.ecmascript.org/show_bug.cgi?id=112).

[bterlson]

Ugh, this is sad. On the one hand, not following ISO-8601 is super confusing and bad, but if we can't do it we can't do it.

@ajklein any way to quantify the breakage any more? Is it sufficient that you are reverting this change and going back to old (presumably interoperable) behavior?

[mattjohnsonpint]

It is indeed a breaking change, but one that myself and others have been watching for some time. I blogged about it a few months ago:
http://codeofmatt.com/2015/06/17/javascript-date-parsing-changes-in-es6/

Lots of StackOverflow on this too:
http://stackoverflow.com/a/19279013/634824
http://stackoverflow.com/a/29185654/634824
http://stackoverflow.com/a/29694450/634824
http://stackoverflow.com/a/32252922/634824
http://stackoverflow.com/a/32786410/634824
(more, I'm sure)

Other's have blogged and commented:
http://blog.niftysnippets.org/2014/07/javascripts-datetime-format-is-not-iso.html
Pikaday/Pikaday#138 (comment)
es-shims/es5-shim#248 (comment)

Even Mozilla has commented in MDN docs that this change is coming:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#Differences_in_assumed_time_zone

Reverting the decision now seems like a bad idea, IMHO.

[mattjohnsonpint]

Also, please consider that there are good reasons for this change.

A major source of confusion amongst web developers (more StackOverflow posts than I can count) is:

new Date("2015-10-15")
// Wed Oct 14 2015 17:00:00 GMT-0700 (Pacific Daylight Time)

Why is the date not what I passed in? Even worse, calling functions like toDateString masks the time component, so it just looks like "Wed Oct 14 2015", even though you passed in 2015-10-14. Of course, this is only if I'm West of UTC. If I'm on the other side of the world it works. So apps get developed often in the Eastern hemisphere (positive offsets) and the bug is masked until users from the Western hemisphere (negative offsets) use it.

With the new spec in place, this problem goes away.

new Date("2015-10-15")
// Thu Oct 15 2015 00:00:00 GMT-0700 (Pacific Daylight Time)

ALSO consider HTML5 interaction. The datetime-local input type provides a value such as "2015-10-15T01:23:45". It is ISO8601 compliant, and is intended to be interpreted as local time - not as UTC.

I'm sure plenty of people are trying to use these together, as in:

<input type="datetime-local" id="foo">

var value = document.getElementById("foo").value;
var dt = new Date(value);

Without this change they'd have to do some string manipulation of the value first. Indeed, people get hung up on this all the time and either manipulate the string, or resort to a library (like moment.js).

[ajklein]

Looping in @ulan, who's been handling the V8 implementation side of this.

[ulan]

To clarify why we are reverting the change in V8:
the original change was landed under the assumption that Firefox and IE already default to local timezone (see https://code.google.com/p/v8/issues/detail?id=4242, http://crbug.com/543320), so the risk of breaking the web was considered low. Unfortunately, we checked parsing only for the "YYYY-MM-DDT00:00:00" and didn't know that Firefox and IE return different result for "YYYY-MM-DD".

We are reverting the change because it turned out to be much more riskier than we thought: Chrome 46 is inconsistent with Firefox, IE, and Safari in parsing of "YYYY-MM-DD", and we are getting bug reports about it.

Andreas and Adam will raise this issue in TC39.

[mattjohnsonpint]

@ulan - Thanks, I didn't realize that IE and FF had already switched to ES6 behavior for YYYY-MM-DDTHH:MM:SS. I hope that the parts being reverted do not undo this part. That at least addresses my concern about the datetime-local HTML5 type.

However - I still think it's the right ting to do to also switch YYYY-MM-DD representations to ES6 behavior. I'm really not sure why FF and IE have not done that. Perhaps they just haven't gotten around to it yet? I don't see why Chrome can't go first and have others follow suit.

Consider:

• There's still the HTML5 date input type, which my above example still applies. (Users in the western hemisphere will get dates one day earlier than the one selected.)
• ES6 § 20.3.1.16 is very clear that the format includes date-only forms, including the complete representation (YYYY-MM-DD) and incomplete representations (YYYY-MM and YYYY). The wording about using local time is part of this same section, so I don't understand why it should be selectively applied to YYYY-MM-DDTHH:MM:SS only.
• ISO8601 is also very specific as to what it considers a "complete representation" vs implementations with "reduced accuracy". Examples in ISO8601:2004(E) § B1.1.1 show YYYY-MM-DD as a complete representation of a calendar date. Examples of complete date and time representations are in § B1.3. I bring this up because sometimes people mistakenly believe that if it doesn't contain a T that it's not ISO8601.

[mattjohnsonpint]

Also consider that in in v8-4242, the reason the test failed was interpreted wrong in the discussion.

In the discussion, its thought that new Date(1970, 0, 1, 0, 0, 0, 0) was incorrectly switched from UTC to local interpretation, when actually passing by argument has always been interpreted as local time, and isn't part of the parsing behavior changes for ES6.

It's actually the other date object in the test new Date("1970") that was being interpreted differently. It would fall under the incomplete representations mentioned in both ES6 and ISO8601, and indeed should be interpreted as local time. Interpreting it as UTC again means that folks in the Western hemisphere are getting different values than those in the Eastern hemisphere.

Consider new Date("1970").getFullYear() which returns 1970 in all browsers for users in the Eastern hemisphere, but returns 1969 for browsers in the Western hemisphere under ES5 rules. Under ES6 rules, both would get 1970.

[bterlson]

I don' think there's any doubt that following ISO8601 (and ES6) would be the ideal here. The problem is that browsers can't break huge swaths of the web as much as we'd like to.

I think the next step here is to see if we can quantify how many sites are at risk for being broken (and how many sites might actually have latent bugs fixed). This will be good information to share with the committee.

[mattjohnsonpint]

Isn't the web already broken with this regard? Date parsing has long been a thorn in the side of JavaScript developers, and the advice for a long time now has been "don't rely on it to behave in any specific manner". I'm sure that's not practical from a spec perspective, but that's reality.

If it were to change as specified, the effect would be limited to those applications that have not already encountered the current behavior's adverse effects. In other words, if I'm using an app with new Date("2015-10-16") then if I have users in the Western hemisphere I will have already encountered the problem of it being interpreted as UTC, and likely found a workaround (such as parsing the string myself with regex or split, or using a library like moment.js.

If I don't have users in the Western hemisphere, and if I mistakenly believed I was getting local time before, then I will see no adverse effects. new Date("2015-01-01").getFullYear() === 2015.

It's only if I explicitly depended on the ambiguous input to be interpreted as UTC that I will see new breakage, and only for Eastern hemisphere users. new Date("2015-01-01").getUTCFullYear() === 2015 under ES5, new Date("2015-01-01").getUTCFullYear() === 2014 under ES6.

[bterlson]

There may in fact be latent bugs in code like new Date("2015-01-01") that taking this change would fix, but we don't have evidence of that. What we do have evidence of is actual people who read the documentation, understood that 2015-01-01 would parse in UTC, and are using the API accordingly. That is why making this change in implementations seems risky and why v8 is (rightfully) worried about web compat.

[mattjohnsonpint]

Ok, I can respect that. In general, is ES5 to ES6 supposed to be non-breaking? Or is there a common way that breaking changes are supposed to be communicated to developers as they are implemented?