Why does Date.parse give incorrect results?

Why does Date.parse give incorrect results?

Case One:
new Date(Date.parse(“Jul 8, 2005”));

Output:
Fri Jul 08 2005 00:00:00 GMT-0700 (PST)
Case Two:
new Date(Date.parse(“2005-07-08”));

Output:
Thu Jul 07 2005 17:00:00 GMT-0700 (PST)

Why is the second parse incorrect?

Solutions/Answers:

Solution 1:

Until the 5th edition spec came out, the Date.parse method was completely implementation dependent (new Date(string) is equivalent to Date.parse(string) except the latter returns a number rather than a Date). In the 5th edition spec the requirement was added to support a simplified (and slightly incorrect) ISO-8601 (also see What are valid Date Time Strings in JavaScript?). But other than that, there was no requirement for what Date.parse / new Date(string) should accept other than that they had to accept whatever Date#toString output (without saying what that was).

As of ECMAScript 2017 (edition 8), implementations were required to parse their output for Date#toString and Date#toUTCString, but the format of those strings was not specified.

As of ECMAScript 2019 (edition 9) the format for Date#toString and Date#toUTCString, have been specified as (respectively):

  1. ddd MMM DD YYYY HH:mm:ss ZZ [(timezone name)]
    e.g. Tue Jul 10 2018 18:39:58 GMT+0530 (IST)
  2. ddd, DD MMM YYYY HH:mm:ss Z
    e.g. Tue 10 Jul 2018 13:09:58 GMT

providing 2 more formats that Date.parse should parse reliably in new implementations (noting that support is not ubiquitous and non–compliant implementations will remain in use for some time).

I would recommend that date strings are parsed manually and the Date constructor used with year, month and day arguments to avoid ambiguity:

// parse a date in yyyy-mm-dd format
function parseDate(input) {
  var parts = input.split('-');
  // new Date(year, month [, day [, hours[, minutes[, seconds[, ms]]]]])
  return new Date(parts[0], parts[1]-1, parts[2]); // Note: months are 0-based
}

Solution 2:

During recent experience writing a JS interpreter I wrestled plenty with the inner workings of ECMA/JS dates. So, I figure I’ll throw in my 2 cents here. Hopefully sharing this stuff will help others with any questions about the differences among browsers in how they handle dates.

The Input Side

All implementations store their date values internally as 64-bit numbers that represent the number of milliseconds since 1/1/1970 UTC (GMT is the same thing as UTC). Dates occurring after 1/1/1970 00:00:00 are positive numbers and dates prior are negative.

Therefore, the following code produces the exact same result on all browsers.

Date.parse('1/1/1970');

In my timezone (EST), the result is 18000000 because that’s how many ms are in 5 hours (it’s only 4 hours during daylight savings months). The value will be different in different time zones. All the major browsers do it the same way.

Here is the rub though. While there is some variance in the input string formats that the major browsers will parse as dates, they essentially interpret them the same as far as time zones and daylight savings are concerned. The one hold out is the ISO 8601 format. It’s the only format outlined in the ECMA-262 v.5 spec specifically. For all other string formats, the interpretation is implementation-dependent. Ironically, this is the format where browsers can differ. Here is a comparison output of Chrome vs Firefox for 1/1/1970 on my machine using the ISO 8601 string format.

Date.parse('1970-01-01T00:00:00Z');       // Chrome: 0         FF: 0
Date.parse('1970-01-01T00:00:00-0500');   // Chrome: 18000000  FF: 18000000
Date.parse('1970-01-01T00:00:00');        // Chrome: 0         FF: 18000000
  • The “Z” specifier indicates that the input is already in UTC time and requires no offset before storage.
  • The “-0500” specifier indicates that the input is in GMT-05:00 so both
    browsers interpret the input as being in my local timezone. That means that the
    value is converted to UTC before being stored. In my case, it means adding 18000000ms to the date’s internal value thus requiring a -18000000ms (-05:00) shift to put me back in local time.
  • When there is no specifier however, FF treats the input as local time while Chrome
    treats it as UTC time. For me this creates a 5 hour difference in the stored value, which is problematic. In my implementation I ended up siding with FF here because I like the output of toString to match my input value unless I specify an alternate timezone, which I never do. The absence of a specifier should presume local time input.

But here is where it gets worse, FF treats the short form of the ISO 8601 format (“YYYY-MM-DD”) differently than it treats the long form (“YYYY-MM-DDTHH:mm:ss:sssZ”) for no logical reason whatsoever. Here is the output from FF with the long and short ISO date formats with no time zone specifier.

Date.parse('1970-01-01T00:00:00');       // 18000000
Date.parse('1970-01-01');                // 0

So, to answer the original asker’s question directly, "YYYY-MM-DD" is the short form of the ISO 8601 format "YYYY-MM-DDTHH:mm:ss:sssZ". So, it is interpreted as UTC time while the other is interpreted as local. That’s why,

This doesn’t jive:

console.log(new Date(Date.parse("Jul 8, 2005")).toString());
console.log(new Date(Date.parse("2005-07-08")).toString());

This does:

console.log(new Date(Date.parse("Jul 8, 2005")).toString());
console.log(new Date(Date.parse("2005-07-08T00:00:00")).toString());

The bottom line is this for parsing date strings. The ONLY ISO 8601 string that you can safely parse across browsers is the long form. And, ALWAYS use the “Z” specifier. If you do that you can safely go back and forth between local and UTC time.

This works across browsers (after IE9):

console.log(new Date(Date.parse("2005-07-08T00:00:00Z")).toString());

Fortunately, most current browsers do treat the other input formats equally, including the most frequently used ‘1/1/1970’ and ‘1/1/1970 00:00:00 AM’ formats. All of the following formats (and others) are treated as local time input in all browsers and converted to UTC before storage. Thus, making them cross-browser compatible. The output of this code is the same in all browsers in my timezone.

console.log(Date.parse("1/1/1970"));
console.log(Date.parse("1/1/1970 12:00:00 AM"));
console.log(Date.parse("Thu Jan 01 1970"));
console.log(Date.parse("Thu Jan 01 1970 00:00:00"));
console.log(Date.parse("Thu Jan 01 1970 00:00:00 GMT-0500"));

The Output Side

On the output side, all browsers translate time zones the same way but they handle the string formats differently. Here are the toString functions and what they output. Notice the toUTCString and toISOString functions output 5:00 AM on my machine.

Converts from UTC to Local time before printing

 - toString
 - toDateString
 - toTimeString
 - toLocaleString
 - toLocaleDateString
 - toLocaleTimeString

Prints the stored UTC time directly

 - toUTCString
 - toISOString 

In Chrome
toString            Thu Jan 01 1970 00:00:00 GMT-05:00 (Eastern Standard Time)
toDateString        Thu Jan 01 1970
toTimeString        00:00:00 GMT-05:00 (Eastern Standard Time)
toLocaleString      1/1/1970 12:00:00 AM
toLocaleDateString  1/1/1970
toLocaleTimeString  00:00:00 AM

toUTCString         Thu, 01 Jan 1970 05:00:00 GMT
toISOString         1970-01-01T05:00:00.000Z

In Firefox
toString            Thu Jan 01 1970 00:00:00 GMT-05:00 (Eastern Standard Time)
toDateString        Thu Jan 01 1970
toTimeString        00:00:00 GMT-0500 (Eastern Standard Time)
toLocaleString      Thursday, January 01, 1970 12:00:00 AM
toLocaleDateString  Thursday, January 01, 1970
toLocaleTimeString  12:00:00 AM

toUTCString         Thu, 01 Jan 1970 05:00:00 GMT
toISOString         1970-01-01T05:00:00.000Z

I normally don’t use the ISO format for string input. The only time that using that format is beneficial to me is when dates need to be sorted as strings. The ISO format is sortable as-is while the others are not. If you have to have cross-browser compatibility, either specify the timezone or use a compatible string format.

The code new Date('12/4/2013').toString() goes through the following internal pseudo-transformation:

  "12/4/2013" -> toUCT -> [storage] -> toLocal -> print "12/4/2013"

I hope this answer was helpful.

Solution 3:

There is some method to the madness. As a general rule, if a browser can interpret a date as an ISO-8601, it will. “2005-07-08” falls into this camp, and so it is parsed as UTC. “Jul 8, 2005” cannot, and so it is parsed in the local time.

See JavaScript and Dates, What a Mess! for more.

Solution 4:

Another solution is to build an associative array with date format and then reformat data.

This method is useful for date formatted in an unussual way.

An example:

    mydate='01.02.12 10:20:43':
    myformat='dd/mm/yy HH:MM:ss';


    dtsplit=mydate.split(/[\/ .:]/);
    dfsplit=myformat.split(/[\/ .:]/);

    // creates assoc array for date
    df = new Array();
    for(dc=0;dc<6;dc++) {
            df[dfsplit[dc]]=dtsplit[dc];
            }

    // uses assc array for standard mysql format
    dstring[r] = '20'+df['yy']+'-'+df['mm']+'-'+df['dd'];
    dstring[r] += ' '+df['HH']+':'+df['MM']+':'+df['ss'];

Solution 5:

According to http://blog.dygraphs.com/2012/03/javascript-and-dates-what-mess.html the format “yyyy/mm/dd” solves the usual problems.
He says: “Stick to “YYYY/MM/DD” for your date strings whenever possible. It’s universally supported and unambiguous. With this format, all times are local.”
I’ve set tests: http://jsfiddle.net/jlanus/ND2Qg/432/
This format:
+ avoids the day and month order ambiguity by using y m d ordering and a 4-digit year
+ avoids the UTC vs. local issue not complying with ISO format by using slashes
+ danvk, the dygraphs guy, says that this format is good in all browsers.

Solution 6:

Use moment.js to parse dates:

var caseOne = moment("Jul 8, 2005", "MMM D, YYYY", true).toDate();
var caseTwo = moment("2005-07-08", "YYYY-MM-DD", true).toDate();

The 3rd argument determines strict parsing (available as of 2.3.0). Without it moment.js may also give incorrect results.