V4's Date claims to extend toLocale*String() in ways expressly forbidden by ECMA-262

• [0] http://www.ecma-international.org/ecma-262/7.0/index.html#sec-forbidden-extensions
• [1] http://www.ecma-international.org/ecma-262/7.0/index.html#sec-date.prototype.tolocaledatestring
• [2] http://www.ecma-international.org/ecma-402/3.0/index.html#sup-properties-of-the-date-prototype-object

In [0], ECMA-262 says that "The behaviour of the following methods must not be extended except as specified in ECMA-402:" and the following list includes Date.prototype.toLocaleDateString, Date.prototype.toLocaleString and Date.prototype.toLocaleTimeString; the referenced allowed extensions are given in [2]. The un-extended versions, in [1], all take two optional parameters, both specified as reserved; each method says "The meaning of the optional parameters to this method are defined in the ECMA-402 specification; implementations that do not include ECMA-402 support must not use those parameter positions for anything else."

• [3] qtdeclarative/src/qml/doc/src/javascript/date.qdoc

In [3] we document our implementations of these methods, giving the two optional reserved parameters meaning as (locale, format). This conflicts with ECMA-402, in which the first is locales (plural; I think it's a list but have yet to dig my way far enough down into that spec) and the second is options (an object with various attributes; a format is derived from it and the locales). V4 thus claims to be in violation of both ECMA-262 and ECMA-402.

• [4] qtdeclarative/src/qml/jsruntime/qv4dateobject.cpp
• [5] qtdeclarative/tests/auto/qml/qqmllocale/data/date.qml
• [6] qtdeclarative/tests/auto/qml/qqmllocale/tst_qqmllocale.cpp

In [4] we implement these methods. I can't see how the implementations access their parameters (to be specific: it looks like they don't) but I find that removing the parameters from a test-case ([5], run by [6]) does cause the test to fail (which it doesn't with the parameters); so clearly the implementation does (somehow) get at its parameters. My investigation continues.

(Neither ECMA spec says anything about Date.fromLocale*String methods; I can't say for certain, but our provision of Date.fromLocale(|Date|Time)String() methods isn't obviously in violation of the spec. The spec allows Date.parse() to recognise assorted implementation-specific formats as long as texts matching the format family defined by the spec do get handled the way the spec asks for; we support diverse formats via QDateTime for this. The fromLocale*String() methods extend this further.)