Am seeking confirmation if this is a bona fide documentation and/or implementation bug with Javascript's Date.parse method.

The docs I'm referring to are at and they say 'If you do not specify a time zone, the local time zone is assumed.'

But the following code shows that, despite not specifying a time zone, local time is not being assumed (but rather my timezone offset is being applied), if the string passed to Date.parse begins with the 4-digit year representation, and is dash-delimited.

var euroStyleDate = '2011-10-04';
var amerStyleDate = '10/04/2011';
var euroStyleParsed = Date.parse(euroStyleDate);
var amerStyleParsed = Date.parse(amerStyleDate);

console.log(euroStyleParsed); //1317686400000
console.log(amerStyleParsed); //1317700800000

console.log(new Date(euroStyleParsed)); 
//Date {Mon Oct 03 2011 20:00:00 GMT-0400 (Eastern Daylight Time)}
console.log(new Date(amerStyleParsed)); 
//Date {Tue Oct 04 2011 00:00:00 GMT-0400 (Eastern Daylight Time)}

There may even be other cases, and I'm sure I'm not the first to discover this if I am incorrect. So beyond confirmation, I'd surely love to be pointed at more in-depth information on this if anybody knows of pertinent links.

I'm experiencing this in FF3, Chrome for Windows and of course just to be special IE8 doesn't even seem to able to perform the conversion on 2011-10-04 whatsoever: I'm just getting an empty string in my application

Thanks in advance for any further insight or resources.

Am seeking confirmation if this is a bona fide documentation and/or implementation bug with Javascript's Date.parse method.

The docs I'm referring to are at https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/parse and they say 'If you do not specify a time zone, the local time zone is assumed.'

But the following code shows that, despite not specifying a time zone, local time is not being assumed (but rather my timezone offset is being applied), if the string passed to Date.parse begins with the 4-digit year representation, and is dash-delimited.

var euroStyleDate = '2011-10-04';
var amerStyleDate = '10/04/2011';
var euroStyleParsed = Date.parse(euroStyleDate);
var amerStyleParsed = Date.parse(amerStyleDate);

console.log(euroStyleParsed); //1317686400000
console.log(amerStyleParsed); //1317700800000

console.log(new Date(euroStyleParsed)); 
//Date {Mon Oct 03 2011 20:00:00 GMT-0400 (Eastern Daylight Time)}
console.log(new Date(amerStyleParsed)); 
//Date {Tue Oct 04 2011 00:00:00 GMT-0400 (Eastern Daylight Time)}

There may even be other cases, and I'm sure I'm not the first to discover this if I am incorrect. So beyond confirmation, I'd surely love to be pointed at more in-depth information on this if anybody knows of pertinent links.

I'm experiencing this in FF3, Chrome for Windows and of course just to be special IE8 doesn't even seem to able to perform the conversion on 2011-10-04 whatsoever: I'm just getting an empty string in my application

Thanks in advance for any further insight or resources.

• javascript
• date

2 Answers 2

I ran into this concept, too. For anyone googling "Javascript dates dashes slashes" like I was, this is the clearest demonstration that I can think of as to what's going on here.

In short, slashes means local time zone, and dashes means UTC. Other answers has explanations regarding why.

<script type="text/javascript">

var 
testB = new Date("2012/02/09"),
testC = new Date("2012-02-09");


alert(testB.toString());
alert(testC.toString());
alert(testC.toUTCString());
</script>

**Update:**It looks like there are several different standards at work here:

1. The EMCAScript < 5 standard allowed for dates in the standard IETF format, e.g. Sun Oct 03 2010. With these dates, the local timezone is assumed.

2. In ECMAScript 5, a limited version of the ISO 8601 standard is also allowed, e.g. 2010-10-03. The spec seems to say (perhaps following ISO 8601?) that in this case, the UTC timezone is assumed if one is not specified.

3. I haven't found a spec that says Date.parse can handle mm/dd/yyyy dates, but my browser (Chrome 14) clearly can, and probably other browsers can too. This appears to follow standard 1 above, assuming the local timezone. Given that it's not in the spec, however, I would recommend not using this version, as it's likely to be browser-dependent (and I have no idea whether 10-03-2010 would result in a different date if I had a European locale set on my browser).

There are a few issues with the native Date.parse function in most interpreters - I have often had timezone issues like the one you describe. So in general, I either use a library like Datejs or I write my own parsing functions. The DateTime module of the SIMILE AJAX library has a pretty good example function for parsing ISO-8601 dates (what you're referring to as euroStyleDate, plus an optional time component).

When setting dates, I generally use new Date() and then use the setUTC*() functions to set the different date elements to my desired precision. It's not perfect, but at least you're dealing with a clear timezone.