gistfile1.txt

// works in production

core:PRIMARY> db.test.insert({test:new Date('2014-01-29 03:00')})
core:PRIMARY> db.test.find().pretty()
{
   "_id" : ObjectId("52e930ef400853587d69153f"),
   "test" : ISODate("1970-01-01T00:00:00Z")
}

// does not work in other dev/local envs
> db.test.insert({test: new Date('2014-01-29 03:00')})
> db.test.find().pretty()
{
    "_id" : ObjectId("52e931403aac5af45aa48fd5"),
    "test" : ISODate("2014-01-29T09:00:00Z")
}

We're running 2.2.4 on all environments.

"2014-01-29 03:00" is not a valid argument to JavaScript's Date constructor. I assume that's the documentation for SpiderMonkey, which is what 2.2.x uses.

$ 2.2.4/bin/mongo --nodb
MongoDB shell version: 2.2.4
> new Date()
ISODate("2014-01-29T22:43:09.245Z")
> new Date('2014-01-29 03:00')
ISODate("0NaN-NaN-NaNTNaN:NaN:NaNZ")
> new Date(2014,0,29,3)
ISODate("2014-01-29T08:00:00Z")

I'm using 0 for January, since indexing starts at zero. 2.4.9 and 2.5.x have the same results, but they seem to be more flexible with parsing single string arguments:

$ 2.4.9/bin/mongo --nodb
MongoDB shell version: 2.4.9
> new Date()
ISODate("2014-01-29T22:43:39.597Z")
> new Date('2014-01-29 03:00')
ISODate("2014-01-29T08:00:00Z")
> new Date(2014,0,29,3)
ISODate("2014-01-29T08:00:00Z")
> 

This may be relevant: http://code.google.com/p/v8/source/browse/trunk/src/date.js#156

@jwage: If it wasn't clear, I think the reason you saw a discrepancy was all to do with people running newer mongo shells, even if the dev environment itself was 2.2.4. The above tests had nothing to do with the server version, since we need to create an ISODate object long before we send anything over the wire, and that happens with the client's JS interpreter.