How to deal with the timezone issue when storing dates in utc using mongod?

Aside from the SERVER-6310 mentioned by Matt Johnson, one other workaround is to use the $project operator to add or subtract from the UTC time zone to "shift the time" into the correct local zone. Turns out you can add or subtract time in milliseconds.

For example, assuming I have a Date field called orderTime. I'd like to query for EDT. That is -4 hours from UTC. That's 4 * 60 * 60 * 1000 milliseconds.

So I would then write the following projection to get day_ordered in local time for all my records:

db.table.aggregate(     { $project : { orderTimeLocal : { $subtract : [ "$orderTime", 14400000] } } },    { $project : { day_ordered : { $dayOfYear : "$orderTimeLocal" } } })

Every approach suggested above works perfectly fine, but since there is a new version of mongodb, from 2.6 you can use $let in the aggregation framework, this will let you create variables on the fly, thus avoiding the need to $project before grouping. Now you could create a variable with $let that will hold the localized time, and use it in the $group operator.

Something like:

db.test.aggregate([   {$group: {         _id: {              $let: {                  vars: {                       local_time: { $subtract: ["$date", 10800000]}                  },                  in: {                     $concat: [{$substr: [{$year: "$$local_time"}, 0, 4]},                               "-",                               {$substr: [{$month: "$$local_time"}, 0, 2]},                               "-",                               {$substr: [{$dayOfMonth: "$$local_time"}, 0, 2]}]                 }              }         },          count: {$sum: 1}     } }])

Notice that you use $let inside definition of a block/variable, and the value of that block/variable is the returned value of the subexpression "in", where the above defined vars are used.

What you're asking for is currently being discussed in MongoDB issue SERVER-6310.

I found this in a link from a discussion thread.

The problem is common for any grouping by date, including SQL databases and NoSQL databases. In fact, I recently addressed this head on in RavenDB. There is a good description of the problem and a RavenDB solution here.

The MongoDB issues discusses a workaround, which is similar to what I described in comments above. You precalculate the local times you are interested in, and group by those instead.

It will be difficult to cover every time zone in the world with either approach. You should decide on a small handful of target zones that make sense for your user base, such as the per-office approach I described in the RavenDB article.

UPDATE: This issue was solved in MongoDB in July 2017 (version 3.5.11). The solution is described in the first link above, but in short they have introduced a new object format for dates in aggregation expressions: { date: <dateExpression>, timezone: <tzExpression> } that allows you to specify a timezone to use when aggregating. See here for another example in the Mongo docs.