Discuss
  • About bugfix: For ISO 8601 syntax, Date.parse should accept " " in places where "T" is allowed

About bugfix: For ISO 8601 syntax, Date.parse should accept " " in places where "T" is allowed

# LittleQ (13 years ago)

I made a patch for bug-791320 [1], and somebody ask me to get opinions from this mailing list.

This patch added support for accepting " " in places where "T" is allowed originally, will it cause any problem.

for example:

"2012-12-12T12:12:12" and the derivation(append millisecond or timezone) will be accepted. "2012-12-12 12:12:12" will be accepted after this patch

and these won't be accepted after this modifying:

"2012-12-12A12:12:12" (A could be replaced by a-zA-Z) "2012-12-12-12:12:12" "2012-12-12:12:12:12"

any comment for this fixing?

Thanks, this is my first patch for firefox :) any advise will be welcome~

*[1] For ISO 8601 syntax, Date.parse should accept " " in places where "T" is allowed.: *bugzilla.mozilla.org/show_bug.cgi?id=791320

# Norbert Lindenberg (13 years ago)

When changing the implementation of a standard built-in function that's defined in the ECMAScript Language Specification, you should always check the specification: ecma-international.org/ecma-262/5.1

In this case, it seems your extension of the accepted formats is allowed by the statement "the function may fall back to any implementation-specific heuristics or implementation-specific date formats". ecma-international.org/ecma-262/5.1/#sec-15.9.4.2

Norbert

# Allen Wirfs-Brock (13 years ago)

This is the response I posted to the bugzilla issue:

I would like to see a better motivation present for why this change is important. In particular, it is a deviation from the ECMAScript standard. While syntactic extensions to the Date.parse syntax is allowed by the specification. It is not particularly a good idea. In particular, every time a specific implementation adds such a non-standard extension, it creates a potential cross-browser interoperability hazard.

Apparently these extensions are not motivated by a desire to improve interoperability as reference [1] shows that none of Firefox, IE, and Safari currently provide these extensions. Chrome apparently does (and also Opera??).

Finally, I don't understand why a WhatWG document is being used to justify a change to an ECMAScript specified function or why the WhatWG is messing with an ECMA specification. If there is a serious proposal to change the ECMAScript specification it should be brought to TC39 as a proposal where it would be given serious consideration. But simply bypassing the standards process doesn't seem like a very good idea. In particular, Google is a member of TC39 and Chrome has apparently implemented these extensions. Yet as far as I know, they have not made a proposal for this extension to TC39. Why not?

# Sigbjorn Finne (13 years ago)

On Wed, Sep 19, 2012 at 3:46 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

This is the response I posted to the bugzilla issue:

I would like to see a better motivation present for why this change is important. In particular, it is a deviation from the ECMAScript standard. While syntactic extensions to the Date.parse syntax is allowed by the specification. It is not particularly a good idea. In particular, every time a specific implementation adds such a non-standard extension, it creates a potential cross-browser interoperability hazard.

Apparently these extensions are not motivated by a desire to improve interoperability as reference [1] shows that none of Firefox, IE, and Safari currently provide these extensions. Chrome apparently does (and also Opera??).

That format has been recognized by Opera's Date parsers for at least 5-6 years. I don't think you'll find there being a reason for that other than a parser that tries to be permissive about formats allowed, and lets that through (which few others have.)

--sigbjorn / sof at opera.com