A Bad Date With Internet Explorer 11: Trouble With New Unicode Characters in Javascript Date Strings

The Problem

I recently discovered an interesting issue with Internet Explorer (IE) 11 after taking IE 11 on a date with some cross-browser testing. Some lazy JavaScript code I’d written to calculate and display calendar dates were rendering as “Invalid Date” in various Html elements. The same JavaScript code worked fine in older versions of IE as well as Firefox and Chrome.

Specifically, any line creating a new JavaScript Date object with a string fetched from the toLocaleDateString method would fail, resulting in the display of “Invalid Date”.

Below is a simplified version of the code.

<span class="hljs-keyword">var</span> localeDateString = <span class="hljs-keyword">new</span> <span class="hljs-built_in">Date</span>().toLocaleDateString();

<span class="hljs-comment">// will show today's date in mm/dd/yyyy format or per your locale settings</span>
<span class="hljs-built_in">console</span>.log(localeDateString);

<span class="hljs-comment">// the lazy code: locale strings are not meant to be used in the Date constructor</span>
<span class="hljs-keyword">var</span> newDate = <span class="hljs-keyword">new</span> <span class="hljs-built_in">Date</span>(localeDateString); 

<span class="hljs-comment">// If IE11, will show "Invalid Date"</span>
<span class="hljs-built_in">console</span>.log(newDate);


For my locale, I would expect to see the date appear in a mm/dd/yyyy format, with a maximum length of 10 characters. However, in IE 11, the length of the string generated by toLocaleString() is reported as 14.

<span class="hljs-keyword">var</span> localeDateString = <span class="hljs-keyword">new</span> <span class="hljs-built_in">Date</span>().toLocaleDateString();

<span class="hljs-comment">// In all browsers, for my locale, shows "8/22/2016"</span>
<span class="hljs-built_in">console</span>.log(localeDateString);

<span class="hljs-comment">// in all browsers but IE 11, shows 9.  In IE 11, 14</span>
<span class="hljs-built_in">console</span>.log(localeDateString.length);


The Unicode Surprise

Let’s take a look at what IE 11 has added to the output of toLocaleDateString(). Run the code below in IE 11

<span class="hljs-keyword">for</span> (<span class="hljs-keyword">var</span> i=<span class="hljs-number">0</span>; i<localeDateString.length;i++) { 
     <span class="hljs-built_in">console</span>.log(i.toString() + <span class="hljs-string">' : '</span> + localeDateString.charCodeAt(i)); 


You should see something like the below, the character index number followed by it’s character code

0  : 8206
1  : 56
2  : 8206
3  : 47
4  : 8206
5  : 50
6  : 50
7  : 8206
8  : 47
9  : 8206
10 : 50
11 : 48
12 : 49
13 : 54


Aha…. character code 8206 has been added and is the Unicode RTL (Right-to-Left) mark and obviously precedes each portion comprising the total date, the mm, the /, the dd, the yyyy. So that’s what has changed.

IE 11 Date Parser Doesn’t Like Unicode Characters

In the code below, we can see that it is the presence of these Unicode RTL marks which gives the IE 11 Date parser trouble when instantiating new Date objects:

<span class="hljs-comment">// no unicode characters</span>
<span class="hljs-keyword">var</span> dateString = <span class="hljs-string">"8/23/2016"</span>;
<span class="hljs-comment">// seems to work fine in all browsers</span>
<span class="hljs-built_in">console</span>.log(<span class="hljs-keyword">new</span> <span class="hljs-built_in">Date</span>(dateString));

<span class="hljs-comment">// grab date string with new Unicode characters</span>
<span class="hljs-keyword">var</span> localeDateString = <span class="hljs-keyword">new</span> <span class="hljs-built_in">Date</span>().toLocaleDateString();

<span class="hljs-comment">// If IE11, will show "Invalid Date"</span>
<span class="hljs-built_in">console</span>.log(localeDateString);


Locale Strings Not Meant for Date Constructors

At the end of the day, the cause of the original problem (“Invalid Date”) was due a combination of lazy JavaScript coding practices with the Date object combined with the new Unicode characters embedded in IE 11’s locale date strings. If I had not attempted to create new Date objects using the output from toLocaleDateString, the problem would not have occurred.

Specifically, strings generated with methods like toLocaleDateString() are intended as convenience methods to display dates only. Given the diversity of possible date string formats with various locales, it would be impossible for any browser’s Date parser to consistently parse every locale date string into a new Date object.

This is why the code below is lazy/not best practices

<span class="hljs-comment">// bad code: should not attempt to parse locale strings when constructing new dates</span>
<span class="hljs-built_in">console</span>.log(<span class="hljs-keyword">new</span> <span class="hljs-built_in">Date</span>(<span class="hljs-keyword">new</span> <span class="hljs-built_in">Date</span>().toLocaleString()));


Cross Browser Compliant Date Parsing

The original issue eventually led me to re-ask the question: “What is the most reliable cross-browser method for creating new JavaScript Date objects?”

If there is a definitive answer out there, please let us know. My investigations did not reveal a definitive answer.

However, it led to these findings:

  • Consistent date handling across browsers remains a tricky and troublesome area for web developers. Because each browser has it’s own internal implementation for how it parses strings into Date objects.
  • Mozilla’s documentation on the Date object suggests using IETF-compliant RFC 2822 or ISO8601 timestamps when creating new Date objects with the dateString constructor, but offers an interesting warning against doing so, even with these two standardized datetime string formats:

    dateString String value representing a date. The string should be in a format recognized by the Date.parse() method (IETF-compliant RFC 2822 timestamps and also a version of ISO8601). Note: parsing of date strings with the Date constructor (andDate.parse, they are equivalent) is strongly discouraged due to browser differences and inconsistencies.

  • momentjs is a popular JavaScript library used for handling cross-browser and regional date formatting and calculation issues. Even it’s documentation cautions against constructing new Date objects with a single string in the constructor:

    Warning: Browser support for parsing strings is inconsistent. Because there is no specification on which formats should be supported, what works in some browsers will not work in other browsers. For consistent results parsing anything other than ISO 8601 strings, you should use String + Format.

The Most Reliable Method Is The Least Convenient

Ultimately, it seems that the most reliable method for creating new JavaScript Date objects is to use the constructor which takes each date part as a separate argument

new Date(year, month[, day[, hour[, minutes[, seconds[, milliseconds]]]]]);


Writing cross-browser compliant JavaScript is obviously important and highly desirable. Handling JavaScript Dates across browsers consistently continues to be an ongoing challenge for web developers because each browser can have slightly different expectations when working with datetime strings.

If you have been using less-than-ideal methods for creating new Date objects, such as passing a single datetime string into the Date constructor, or using Date.parse, consider converting your code to create new Date objects with the

new Date(year, month[, day[, hour[, minutes[, seconds[, milliseconds]]]]]);

constructor in order to avoid cross-browser differences when parsing dates. Even then, you may need to still handle some browser differences. In many cases, libraries like momentjs may help ease cross-browser pain when working with dates.

Finally, IE 11 has begun to emit Unicode RTL marks into the datetime strings emitted by it’s various toLocaleString() methods, which causes “Invalid Date” to appear when attempting to create new Date objects with the Date(dateString) constructor and the Date.parse(dateString) method. The newly embedded Unicode characters may cause your existing JavaScript to fail.

Please post any comments, feedback or questions below.

Ted Bicknell

Ted Bicknell

Ted Bicknell is a Senior Software Engineer, and formerly an expert SharePoint consultant who provided technical guidance to companies spanning industries. He teamed up with CSG Pro as a Sharepoint Technology Preferred Partner and eventually stepped into his current role. Now Ted leverages the latest front-end frameworks for the full gamut of web application development, guiding clients with his technological know-how so they can improve their business processes.
Share on twitter
Share on facebook
Share on linkedin
Share on email
Stay Connected

Subscribe to CSG Pro. We’ll supply your inbox with the latest blog posts, training videos, and upcoming events.


Ready to wrangle your data?