Date.parse return type
On Jul 23, 2007, at 10:23 AM, doekman at gmail.com wrote:
In the public Date/time proposal, the Date.parse static method
returns a Date. This is a bit odd, because the current javascript
Date.parse method returns a number (nr. of ms since epoch). Is this
by design?
That's a mistake, which Lars noticed and corrected recently.
Is there some compatibility-strategy defined? I couldn't find one...
The strategy is backward compatibility except in a few hard cases
where the current (since 1997, ES1) semantics are so confusing and
buggy that cleanups probably improve real-world code correctness. See
developer.mozilla.org/es4/proposals/bug_fixes.html.
On 7/23/07, Brendan Eich <brendan at mozilla.org> wrote:
On Jul 23, 2007, at 10:23 AM, doekman at gmail.com wrote:
In the public Date/time proposal, the Date.parse static method returns a Date. This is a bit odd, because the current javascript Date.parse method returns a number (nr. of ms since epoch). Is this by design?
That's a mistake, which Lars noticed and corrected recently.
OK, that's clear. But does Date.parse("2007-07-28") raise a SyntaxError, or does it return NaN?
Same as ever (backward compatibility): NaN.
On 7/28/07, doekman at gmail.com <doekman at gmail.com> wrote:
On 7/23/07, Brendan Eich <brendan at mozilla.org> wrote:
On Jul 23, 2007, at 10:23 AM, doekman at gmail.com wrote:
In the public Date/time proposal, the Date.parse static method returns a Date. This is a bit odd, because the current javascript Date.parse method returns a number (nr. of ms since epoch). Is this by design?
That's a mistake, which Lars noticed and corrected recently.
OK, that's clear. But does Date.parse("2007-07-28") raise a SyntaxError, or does it return NaN?
No SyntaxError is ever thrown. We've decided that was a bug that crept into the proposal.
What Date.parse returns for that string is implementation dependent. Date.parse is only required to correctly parse two classes of strings: those produced by Date.prototype.toString (this is the only requirement of ES3), and strings conforming to the ISO date syntax profile used by ECMAScript 4. A string of the latter class always contains the letter 'T' even if there is no time in the string, only a date.
In practice implementations use all sorts of heuristics for parsing dates and it's exceedingly likely that most implementations will understand your string as 28 July 2007, ie, in answer to your question, "neither".
We've opted not to specify that they must understand it in that way, though. It is possible that this particular case should be brought in under the ISO syntax umbrella, but beyond that it's a slippery slope. We don't really feel that we should define Date.parse much more tightly than we do, for backwards compatibility reasons.
On Jul 28, 2007, at 11:21 AM, Lars T Hansen wrote:
Date.parse("2007-07-28")
SpiderMonkey:
js> Date.parse("2007-07-28")
NaN
We've never had a bug filed asking for this to work because it works
in IE (does it? I can't test atm). But anyway, Lars is right in
general; my answer was based on Firefox only. Per the fine spec
(since Edition 1 :-P), the result is implementation-defined.
IE doesn't either (though Opera does). I'm stunned. That does it -- this format goes into the date proposal as a variant of the ISO syntax, which will be good since it makes the ES4 ISO syntax more compatible with the syntax defined in the W3C date note. (Also accepting "2007" and "2007-07" would make it fully compatible.)
In the public Date/time proposal, the Date.parse static method returns a Date. This is a bit odd, because the current javascript Date.parse method returns a number (nr. of ms since epoch). Is this by design? Another question. Now Date.parse returns NaN, when the date is not parsible. Will this behaviour also be changed?
Is there some compatibility-strategy defined? I couldn't find one...