Javascript Date.parse bug when dash-delimited and starts with year

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 s开发者_运维技巧eem 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.

---

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.