What is the correct way to handle time zones with PyMongo?
Prior to PyMongo version 1.7, the correct way is to only save naive datetime instances, and to save all dates as UTC. In versions >= 1.7, the driver will automatically convert aware datetimes to UTC before saving them. All datetimes retrieved from the server (no matter what version of the driver you’re using) will be naive and represent UTC.
Warning
Be careful not to save naive datetime instances that are not UTC (i.e. the result of calling datetime.datetime.now()).
Something like pytz can be used to convert dates to localtime after retrieving them from the database.
---------------------------------------------------naive 和 aware的区别:
There are two kinds of date and time objects: “naive” and “aware”. This distinction refers to whether the object has any notion of time zone, daylight saving time, or other kind of algorithmic or political time adjustment. Whether a naive datetime object represents Coordinated Universal Time (UTC), local time, or time in some other timezone is purely up to the program, just like it’s up to the program whether a particular number represents metres, miles, or mass. Naive datetime objects are easy to understand and to work with, at the cost of ignoring some aspects of reality.
For applications requiring more, datetime and time objects have an optional time zone information attribute, tzinfo, that can be set to an instance of a subclass of the abstract tzinfo class. These tzinfo objects capture information about the offset from UTC time, the time zone name, and whether Daylight Saving Time is in effect. Note that no concrete tzinfo classes are supplied by the datetime module. Supporting timezones at whatever level of detail is required is up to the application. The rules for time adjustment across the world are more political than rational, and there is no standard suitable for every application.