Closed Bug 1297984 Opened 3 years ago Closed 3 years ago

Date().toLocaleString() output differs from object.toLocaleString()

Categories

(Core :: JavaScript: Standard Library, defect)

defect
Not set

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox51 --- affected

People

(Reporter: jhorak, Unassigned)

Details

Attachments

(1 file)

Attached file testcase.html
The Date().toLocaleString returns different value that object.toLocaleString(), see code below (output of attached testcase)

Source:
  var i_today = new Date();
  document.write("i_today.toLocaleString: " + i_today.toLocaleString()+"\n");
  document.write("Date().toLocaleString:  " + Date().toLocaleString()+ "\n");
Result:
i_today.toLocaleString: 8/25/2016, 1:04:10 PM
Date().toLocaleString:  Thu Aug 25 2016 11:34:10 GMT+0200 (CEST)
The time offset occurs when timezone is se to IRDT, ie output is:

i_today.toLocaleString: 8/25/2016, 1:16:45 PM
Date().toLocaleString:  Thu Aug 25 2016 14:16:45 GMT+0430 (IRDT)
i_today.toLocaleString() is calling Date.prototype.toLocaleString on a Date object, with behavior loosely defined by ECMA-402's definition of that function.

Date().toLocaleString() is calling Object.prototype.toLocaleString on a string value whose contents are loosely defined by ECMA-262 in the ToDateString(time value), which elaborately has the effect of returning that string value.

Put simply, the strings are computed by two entirely different algorithms, that may produce entirely different results.  The specs *permit* the two algorithms to have the same behavior.  But they don't require it.

The ECMA-402 behavior has a bunch more overhead than the algorithm we use for ToDateString, so I don't think we should, purely because we want to and not because specs require it, change these two algorithms to do the same thing.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
Interesting, thanks for explanation!
You need to log in before you can comment on or make changes to this bug.