308132 - wrong string representation of Date object created with an invalid date string

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Yuh-Ruey Chen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

Suppose a Date object is created with an invalid date string, e.g. new
Date('akjsghkjfghsdlfkg'). Calling this object's toString() returns the string
"Invalid Date". Both IE and Opera return the string "NaN" instead.

Both Date.parse('kglsdkfjghsldkfjg') and (new Date('lkjhlkjshgsdg')).valueOf()
return the value NaN as expected.

Reproducible: Always

Steps to Reproduce:
(new Date('kjhglkfjghlsdfkg')).toString()
Actual Results:  
"Invalid Date"

Expected Results:  
"NaN"

Comment 1

[Yuh-Ruey Chen]

Attachment: testcase

For reference:

new Date (value)
The [[Prototype]] property of the newly constructed object is set to the
original Date prototype object,
the one that is the initial value of Date.prototype (15.9.4.1).
The [[Class]] property of the newly constructed object is set to "Date".
The [[Value]] property of the newly constructed object is set as follows:
1. Call ToPrimitive(value).
2. If Type(Result(1)) is String, then go to step 5.
3. Let V be ToNumber(Result(1)).
4. Set the [[Value]] property of the newly constructed object to TimeClip(V)
and return.
5. Parse Result(1) as a date, in exactly the same manner as for the parse
method (15.9.4.2); let V
be the time value for this date.
6. Go to step 4.

TimeClip (time)
The operator TimeClip calculates a number of milliseconds from its argument,
which must be an
ECMAScript number value. This operator functions as follows:
1. If time is not finite, return NaN.
2. If abs(Result(1)) > 8.64 x 1015, return NaN.
3. Return an implementation-dependent choice of either ToInteger(Result(2)) or
ToInteger(Result(2)) + (+0).
(Adding a positive zero converts −0 to +0.)
NOTE
The point of step 3 is that an implementation is permitted a choice of internal
representations of time
values, for example as a 64-bit signed integer or as a 64-bit floating-point
value. Depending on the
implementation, this internal representation may or may not distinguish
−0 and +0.

Comment 2

[Aiko]

Given the wording in ECMA-262 3rd edition, Mozilla's text seems better. Quote:

15.9.5.2 Date.prototype.toString()

This function returns a string value. The contents of the string are
implementation-dependent, but are intended to represent the Date in the current
time zone in a convenient, human-readable form.

"Invalid date" is more human-readable than "NaN", isn't it? Date.parse and
Date.prototype.valueOf both return a number so these methods have to return NaN.

Comment 3

[Yuh-Ruey Chen]

Well, it depends on what you consider more important: cross-browser consistency,
or a more "human-readable form".

Comment 4

[Bob Clary [:bc] (inactive)]

I think we are on solid ground here and am going to mark this as invalid. If you
can document how changing our implementation will help improve compatibility by
showing which sites or applications would be fixed by this change and that the
benefit outweights any sites or applications which are broken, the issue can be
revisited.