Question

I’m getting a date string in the form "2011-01-27T04:59:00Z" from a web service call. Firefox and Chrome have no problem parsing the string with var d = new Date("2011-01-27T04:59:00Z"), but Safari and IE won’t stand for it.

I can parse the string myself and feed it to Date.parse() or Date.UTC(), but I’m wondering why (1) such a disparity exists among browsers in something so basic as a Date object, and (2) why a public API would return a date string in a format that is rejected by Safari and (especially) IE.

Answer 1

For you two questions, I would say

1. It’s a relic from pre-Browser War I. ECMAScript spec was poorly written, and browser supports whatever they (don’t) want to.
2. It’s ISO 8601 format, invented years after Javascript Date object. Even in php it was added after php 5.0. Date object was original design to take RFC 2822 format.

Corrections per comments:

1. Date.prototype.parse was introduced without a specification that state the date format it should support. Even when it was standardized in ECMAScript 3, the spec didn’t define what date format it should support. In Dec. 2009, ECMAScript 5 defined that Date should support ISO 8601 format as specified in the question, yet for released versions, at time of writing, only Gecko/Firefox implemented the feature. (Webkit had implemented in the nightly version from my test)
2. For unknown reason, even though ISO 8601 was written in 1988, it was not until recently the web protocols/programming languages had begun support the format. PHP supported the format in date() function only after version 5. At the beginning of the Internet, protocols are used to take time in RFC 822/2822 format, which is human-readable for English users.
3. In my opinion, an API should use Unix time to describe time if it’s only intend for machines.