This is actual a fare bigger issue, both in Doctrine and Propel. The source of the troubles are RDBMS that don’t store timezones (most popular: MySQL). And even if the database supports timezones (such as Postgres), the ORMs ignore them by transforming all DateTimes to something like “Y-m-d H:i:s”. (At this point I must admit that I don’t know if Doctrine2 keeps the timezone when using Postgres. Propel doesn’t).

The only valid solution is quite easy in theory, but somewhat cumbersome when implemented: set the server timezone to UTC (no excuses), and filter all DateTime in- and output. This is the ONLY way to keep all DateTime information accurate (think DST!).

I once implemented such a layer for sf1 (together with generic configurable datetime rendering logic), but it’s not ready for publication yet. I eased the usage by providing accessors through a Propel behavior and form widgets and validators to convert user input.

Beware of the timezone! Always…

Mmh, i think it is no mongodb specific problem too. When you have to work with timezones, switch to UTC as system timezone and store every timestamp in UTC then. The application has to decide then how the data has to be transformed to fullfil the user’s needs.

Check this blog post from Kris http://kriswallsmith.net/post/136226720/doctrine-timestamps-and-user-timezones. I did some equal stuff for one symfony1 project and it worked quite well.

The article is wrong, in that MongoDB *is* aware of timezones and stores it as part of the date object. Here’s an example, from a one-year-old blog post:

http://www.lightcubesolutions.com/blog/?p=373

The 1.8 series started representing the date objects as objects, whereas the old 1.6 used to make them look like strings (when they were not, causing a ton of confusion). I’m assuming this is what led the author to assume that MongoDB wasn’t aware of timezones.

Using the mongo shell, you can create a standard javascript date() object, just to demonstrate:

> thingie = {one: "foo", two: "bar", when: new Date()};
{
        "one" : "foo",
        "two" : "bar",
        "when" : ISODate("2011-09-02T09:09:30.588Z")
}
> db.deleteme.save(thingie);
> db.deleteme.findOne();
{
        "_id" : ObjectId("4e609d63c632112c8fb4fae7"),
        "one" : "foo",
        "two" : "bar",
        "when" : ISODate("2011-09-02T09:09:30.588Z")
}

Hope this clears things up, the issue isn’t MongoDB but the way doctrine is forced to generalize date formats across many disparate systems (some of which do a really poor job of timezone support).