HTML date format and Date.parse()
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: 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. 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.
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.
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.
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,
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.
On Tue, Apr 30, 2013 at 4:34 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
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.
There's a difference, though, between adding and removing functionality. Adding support for spaces in 15.9.1.15 is backward-compatible. Removing support for spaces from HTML, as you propose, wouldn't be.
ES6 annex B is the appropriate place to define browser host web reality extensions to Date.parse.
I'm proposing a one-line change to 15.9.1.15 (allow a space in place of 'T') and an equally minor change to 15.9.1.15.1 (extended years), plus a sentence or two of rationale. The proposal has nothing to do with the unspecified legacy formats.
I agree it'd be nice to get the intersection of those formats documented, but it's a tangent.
For that reason, it would probably be better to define "static" methods for parsing specific formats. For example, Date.parseHTMLDate(str) //only recognizes whatever HTML defines
The reason I propose changing 15.9.1.15 is to have one less thing to remember. To unify, since we actually have an opportunity to do that here, for once!
Why is it important to have Date.parse("2013-01-01 10:30Z") return NaN?
(13/04/28 22:36), Allen Wirfs-Brock wrote:
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.
The natural fit would be JS users and I think it would be fine to say that W3C HTML WG represents this party.
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.
But the HTML spec is not aligning with current browser reality for Date.parse :(
(13/05/01 23:45), Jason Orendorff wrote:
On Tue, Apr 30, 2013 at 4:34 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
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.
There's a difference, though, between adding and removing functionality. Adding support for spaces in 15.9.1.15 is backward-compatible. Removing support for spaces from HTML, as you propose, wouldn't be.
Right. But before thinking about HTML, it might be useful to ask if V8/nodeJS, being a non-browser ES implementation, is willing to remove support for spaces?
On Wed, May 1, 2013 at 5:45 PM, Jason Orendorff <jason.orendorff at gmail.com> wrote:
On Tue, Apr 30, 2013 at 4:34 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
ES6 annex B is the appropriate place to define browser host web reality extensions to Date.parse.
I'm proposing a one-line change to 15.9.1.15 (allow a space in place of 'T') and an equally minor change to 15.9.1.15.1 (extended years), plus a sentence or two of rationale. The proposal has nothing to do with the unspecified legacy formats.
I agree it'd be nice to get the intersection of those formats documented, but it's a tangent.
For that reason, it would probably be better to define "static" methods for parsing specific formats. For example, Date.parseHTMLDate(str) //only recognizes whatever HTML defines
The reason I propose changing 15.9.1.15 is to have one less thing to remember. To unify, since we actually have an opportunity to do that here, for once!
Why is it important to have Date.parse("2013-01-01 10:30Z") return NaN?
Can we please reconsider this? Getting HTML and ES more aligned would be so nice :-)
The HTML spec for parsing date and time values is slightly more lenient than ES.
The differences are:
Can ES adopt these changes? It seems to me HTML and JS might as well have the same rules for this sort of thing.
HTML: 2.4.5.5 Local dates and times www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#local-dates-and-times
ES: 15.9.4.2 Date.parse (string) people.mozilla.com/~jorendorff/es6-draft.html#sec-15.9.4.2
ES: 15.9.1.15 Date Time String Format people.mozilla.com/~jorendorff/es6-draft.html#sec-15.9.1.15
Some old discussion in Mozilla's bug-tracking system, no real conclusion: bugzilla.mozilla.org/show_bug.cgi?id=791320