Update October 2014: The draft ES6 specification has changed the timezone thing so ES6 will match ISO-8601 and assume local time, and some implementations (such as V8 in Chrome) have already updated their handling to implement that change.
- ISO-8601 has week numbers, and Here There Be Dragons:
- ISO-8601 allows fractions (of any length) on the smallest time unit in the string, so
2014-07-29T02.5Zis 2:30 in the morning UTC (so is
.(only, not the
,) to separate seconds from an optional milliseconds value (which is very like allowing up to three digits of a fraction on seconds).
- And so on. ISO-8601 covers various other kinds of time spans and all kinds of things.
Date object has no way of representing a span of time (the entire month of May, for instance).
Time Zone Differences
Update (October 2014): See above, ES6 fixes this. I guess they decided it was a bug after all.
In New York, in ISO-8601,
Z (UTC). This is a pretty big difference.
2014-01-01T01:28:55 isn't even in the same year in the two systems in New York (or about half the rest of the planet).
Why would TC-39 (the committee that steers ECMAScript) do something so bone-headed? It probably wasn't bone-headed. Remember that this didn't come in until ECMAScript 5th edition, in 2009. Most likely, engines had been parsing strings like
YYYY-MM-DD in UTC for years. TC-39 couldn't just waive a wand over it and say "Thou shalt now use local time." Too much existing code would break.
My only quarrel is with the wording in the specification, which says that the format is a "simplification" of ISO-8601. "Simplification" (to me) implies "subset," as in, a string that's valid in the subset will mean the same thing in the superset. But that's not true here. They probably should have just said "It looks a bit like ISO-8601, but it isn't" and highlighted the more important differences.