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

Status: RESOLVED WONTFIX

(Core :: JavaScript: Standard Library, defect)

Description

[Jan Horak [:jhorak]]

Attachment: 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)

Comment 1

[Jan Horak [:jhorak]]

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)

Comment 2

[Jeff Walden [:Waldo]]

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.

Comment 3

[Jan Horak [:jhorak]]

Interesting, thanks for explanation!