On Apr 29, 2013, at 11:10 AM, Jason Orendorff wrote:

> On Sun, Apr 28, 2013 at 9:36 AM, Allen Wirfs-Brock
> <allen at wirfs-brock.com> wrote:
>> 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.
> 
> I think I disagree with the premise that a careful reading of the
> vaguer parts of ISO 8601 is likely to help.
> 
> ES and HTML each specify a date-time syntax already (each with a
> *non-normative* reference to ISO 8601). I'm just suggesting that they
> specify the same one, for consistency and interoperability. They're
> nearly identical already.
> 
>>> 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.
> 
> Do you mean: achieve consistency by having HTML retract its extensions
> to ISO 8601? I'm pretty sure that ship has sailed.

Strictly speaking, so has ES55/5.1's date format. 

> 
>> 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.
> 
> Creating a new and separate standard over a few minor date-time syntax
> tweaks sounds like overkill.

ES6 annex B is the appropriate place to define browser host web reality extensions  to Date.parse.  There is a general intent to do this for ES6, but I don't know of anyone having done the work to actually figure out the  de facto standard extensions  in browsers.  My understanding is that it isn't just minor variations of ISO 8601 but also recognition  of some completely different formats which may have been introduced by IE<=6 and probably Netscape. If we can figure out what the web reality is, we'll put in in annex B.

Regarding new extendd date formats, I would prefer not to just added them to the "implementation defined" catch-all of Date.parse. The problem with that approach is that if a program has a specific date format that it want to parse it has no way telling whether it was presented a valid date in that format or a bogus date that just happened to be recognized as something by some implementation defined format extension.

For that reason, it would probably be better to define "static" methods for parsing specific formats. For example,
Date.parseISOString(str) //only recognizes the format defined in http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15 
Date.parseHTMLDate(str) //only recognizes whatever HTML defines in http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#dates-and-times 
Date.parseISO8601(str)  // supports the full 8601 format
//etc.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130430/ee1915c7/attachment.html>

On Apr 29, 2013, at 11:10 AM, Jason Orendorff wrote:

> On Sun, Apr 28, 2013 at 9:36 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>>> 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.
> 
> Do you mean: achieve consistency by having HTML retract its extensions
> to ISO 8601? I'm pretty sure that ship has sailed.

Strictly speaking, so has ES55/5.1's date format. 

>> 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`.
> 
> Creating a new and separate standard over a few minor date-time syntax tweaks sounds like overkill.

ES6 annex B is the appropriate place to define browser host web reality extensions  to `Date.parse`.  There is a general intent to do this for ES6, but I don't know of anyone having done the work to actually figure out the  de facto standard extensions  in browsers.  My understanding is that it isn't just minor variations of ISO 8601 but also recognition  of some completely different formats which may have been introduced by IE<=6 and probably Netscape. If we can figure out what the web reality is, we'll put in in annex B.

Regarding new extendd date formats, I would prefer not to just added them to the "implementation defined" catch-all of `Date.parse`. The problem with that approach is that if a program has a specific date format that it want to parse it has no way telling whether it was presented a valid date in that format or a bogus date that just happened to be recognized as something by some implementation defined format extension.

For that reason, it would probably be better to define "static" methods for parsing specific formats. For example,

```js
Date.parseISOString(str) //only recognizes the format defined in http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15 
Date.parseHTMLDate(str) //only recognizes whatever HTML defines in http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#dates-and-times 
Date.parseISO8601(str)  // supports the full 8601 format
//etc.
```