ToLocaleDateString() changes in IE11

Question

In IE 11, I'm getting funny results with ToLocaleDateString(). The string returned looks fine in the browser, e.g. "1/28/2014 11:00:46 AM", but then if I copy and paste that value into a plain text editor, it looks like this: "?1?/?28?/?2014 ?11?:?00?:?46? ?AM".

Interestingly, if I paste the text into a Microsoft product, it looks fine... The issue is that if you try to use the value programmatically to create a date, it's invalid. You can test this by just opening up a console in IE11 and creating a new date, using ToLocaleDateString() on it, and then trying to use the resulting string to create a new date in javascript or in the language of your choice (I'm using ASP.NET here...).

Am I doing something wrong, or is there some other way I'm supposed to be interacting with the javascript Date? How can I get rid of those funky symbols?

Edit: Thanks to the comment below I was able to figure out what the unshown characters are, they're Left-To-Right marks. Depending on the editor I paste the values into and the encoding that the editor is set to use, the text will show up differently: sometimes with "?", sometimes without.

Answer 1

I fixed that with the following replace(/[^ -~]/g,'') as in

(new Date("7/15/2014").toLocaleString().replace(/[^ -~]/g,'')

Answer 2

The issue is that if you try to use the value programmatically to create a date, it's invalid.

...

Am I doing something wrong, or is there some other way I'm supposed to be interacting with the javascript Date?

Yes, you are doing it wrong. You shouldn't be using a function intended to format something for locale-specific human display and expect the output to be machine parsable. Any of the output of toLocaleString, toLocaleDateString, or toLocaleTimeString are meant for human-readable display only. (As Bergi clarified in comments, toString is also meant for human display, but ECMA §15.9.4.2 says it should round-trip)

You are likely getting the LTR markers because your display locale is RTL. Besides this, consider that the locale will always affect the output. Perhaps your locale uses dd/mm/yyyy formatting instead of mm/dd/yyyy formatting. Or perhaps your locale requires Asian or Arabic characters. These are all considerations when determining a display format, but are never appropriate for machine parsing.

Also consider that the ECMAScript specification does not define any particular formatting rules for the output of these methods, and different browsers will yield different results.

If the intent is anything other than to display to the user, then you should use one of these functions instead:

• toISOString will give you an ISO8601/RFC3339 formatted timestamp
• toGMTString or toUTCString will give you an RFC822/RFC1123 formatted timestamp
• getTime will give you an integer Unix Timestamp with millisecond precision

All of the above will return a UTC-based value. If you want the local time, you can either build your own string with the various accessor functions (getFullYear, getMonth, etc...), or you can use a library such as moment.js:

This uses moment.js to return an ISO8601 formatted local time + offset from a date:

moment(theDate).format()   // ex:  "2014-08-14T13:32:21-07:00"

Answer 3

function FixLocaleDateString(localeDate) {
    var newStr = "";
    for (var i = 0; i < localeDate.length; i++) {
        var code = localeDate.charCodeAt(i);
        if (code >= 47 && code <= 57) {
            newStr += localeDate.charAt(i);
        }
    }
    return newStr;
}

Only returns digits and the / character. Seems to make this work:

new Date(FixLocaleDateString(new Date("7/15/2014").toLocaleString()));

Returns the correct date. Without the call to FixLocaleDateString(), the result would be an invalid date.