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.
Only returns digits and the / character. Seems to make this work:
Returns the correct date. Without the call to FixLocaleDateString(), the result would be an invalid date.
I fixed that with the following
replace(/[^ -~]/g,'')
as inif you also want to remove time use
.split(' ').slice(0, -1).join(' ');
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
, ortoLocaleTimeString
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 timestamptoGMTString
ortoUTCString
will give you an RFC822/RFC1123 formatted timestampgetTime
will give you an integer Unix Timestamp with millisecond precisionAll 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:
For completeness, answer form:
On my system, IE 11's Date object's method
toLocaleDateString
results in"7/6/2014"
when run in the Console which is represented as the following bytes:The non-printables are
0xe2 0x80 0x8e
throughout which is the UTF-8 representation of Unicode Code Point U+200E. Which is, as the comments above say, the LEFT-TO-RIGHT MARK.This JSFiddle doesn't seem to have trouble using the value returned from
toLocaleDateString()
to get back to a date. At least in my IE 11.0.9600.17239 with Update Version 11.0.11 (KB2976627). So maybe only the console adds the extra characters?