On Apr 25, 2013, at 10:43 PM, Jason Orendorff wrote: > The HTML spec for parsing date and time values is slightly more lenient than > ES.
The primary requirement of Date.parse is that it must be able to unambiguously recognize any date encoded in the date-time format defined in section 15.9.1.15: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.9.1.15 . This is the date generated by toISOString and the intend is to guarantee that dates generated via toISOString will always be recognized by Date.parse. For such interchange purposes, I don't think is is necessary to relax the date format rules. Note that ISO 8601 says that formatting simplifications such as leaving out the T is permitted with mutual agreement between the parties interchanging a data. It isn't clear who the other party is that Ecma-262 could reach such an agreement with. Regardless, the specification of Date.parse allows implementation dependent interpretation of inputs that don't conform to the 15.9.1.15 format so an implementation can accept other data formats. My understanding is that browsers implementations typically accept a lot of things as valid dates but that there is no browser independent specification for this. I don't think it is necessarily a good idea for Ecma-262 to require all Es implementations to conform to the intersection of what browsers currently recognized. However, it seems quite reasonable that some W3C spec. (WebIDL? is anyplace else that takes about hosting ES in the browser) defines the browser required "implementation dependent" Date.parse fallback formats > > The differences are: > - HTML allows more-than-4-digit years. The Ecma-262 format allows 6 digits, as long there is a + or - prefix. http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.9.1.15.1 > - HTML allows the seconds and milliseconds to be omitted. This is already allowed by 15.9.1.15: "following time forms with an optional time zone offset appended: THH:mm THH:mm:ss THH:mm:ss.sss " > - HTML allows the "T" in the middle to be replaced with a single space. > > Can ES adopt these changes? It seems to me HTML and JS might as well > have the same rules for this sort of thing. Or maybe we should both just stick to a valid subset of ISO 8601. Like I said above, I think it would be fine for there to be a spec. that adds additional browser implementation spec. format extensions for Date.parse. However, it should only just align with the HTML spec. It also needs to align with the current browser reality for Date.parse. Allen > > HTML: 2.4.5.5 Local dates and times > http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#local-dates-and-times > > ES: 15.9.4.2 Date.parse (string) > https://people.mozilla.com/~jorendorff/es6-draft.html#sec-15.9.4.2 > > ES: 15.9.1.15 Date Time String Format > https://people.mozilla.com/~jorendorff/es6-draft.html#sec-15.9.1.15 > > Some old discussion in Mozilla's bug-tracking system, no real conclusion: > https://bugzilla.mozilla.org/show_bug.cgi?id=791320 > > -j > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
