深入理解Django时区及naive datetime object和aware datetime object的区别

编者的话: 本文转自csdn，原作codeLeaves。自己偶然读到此文，觉得原作写得不错，故分享给大家。如果你要在Django视图和模板中正确使用DateTime类型的数据，除了要阅读Django基础(32)：按日期与时间字段查询数据及模板中日期时间类型数据的格式化及比较，还必须要对timezone非常了解，才能避免如RuntimeWarning: DateTimeField Article.pub_date received a naive datetime 这种新手必犯的错误。

引言

相信使用Django的各位开发者在存储时间的时候经常会遇到这样子的错误:

RuntimeWarning: DateTimeField received a naive datetime while time zone support is active.

这个错误到底是什么意思呢？什么是naive datetime object？什么又是aware datetime object？ 在Django配置中如果将settings.TIME_ZONE设置为中国时区（Asia/Shanghai），为什么以下时间函数(now)会得到时间相差较大的结果？

# settings.py
TIME_ZONE = 'Asia/Shanghai'
# python manage.py shell
>>> from datetime import datetime
>>> datetime.now()
datetime.datetime(2016, 12, 7, 12, 41, 22, 729326)
>>> from django.utils import timezone
>>> timezone.now()
datetime.datetime(2016, 12, 7, 4, 41, 36, 685921, tzinfo=)

接下来笔者将详细揭秘在Django中关于时区的种种内幕，如有不对，敬请指教。

准备

UTC与DST

UTC可以视为一个世界统一的时间，以原子时为基础，其他时区的时间都是在这个基础上增加或减少的，比如中国的时区就为UTC＋8。DST（夏时制, day saving time）则是为了充分利用夏天日照长的特点，充分利用光照节约能源而人为调整时间的一种机制。通过在夏天将时间向前加一小时，使人们早睡早起节约能源。虽然很多西方国家都采用了DST，但是中国不采用DST。（资料来源：DST 百度百科）

naive datetime object vs aware datetime object

当使用datetime.now()得到一个datetime对象的时候，此时该datetime对象没有任何关于时区的信息，即datetime对象的tzinfo属性为None(tzinfo属性被用于存储datetime object关于时区的信息)，该datetime对象就被称为naive datetime object。

>>> import datetime
>>> naive = datetime.datetime.now()
>>> naive.tzinfo #None

既然naive datetime object没有关于时区的信息存储，相对的aware datetime object就是指存储了时区信息的datetime object。

在使用now函数的时候，可以指定时区，但该时区参数必须是datetime.tzinfo的子类。(tzinfo是一个抽象类，必须有一个具体的子类才能使用，笔者在这里使用了pytz.utc，在Django中的timezone源码中也实现了一个UTC类以防没有pytz库的时候timezone功能能正常使用)

>>> import datetime
>>> import pytz
>>> aware = datetime.datetime.now(pytz.utc)
>>> aware
datetime.datetime(2016, 12, 7, 8, 32, 7, 864077, tzinfo=)
>>> aware.tzinfo

在Django中提供了几个简单的函数如is_aware, is_naive, make_aware和make_naive用于辨别和转换naive datetime object和aware datetime object。

timezone.now() vs datetime.now()

笔者在前面花费了大量的篇幅来讲datetime.now的函数并且提及了TZ这一个环境变量，这是因为在Django导入settings的时候也设置了TZ环境变量。TZ就是timezone的缩写。

当执行以下语句的时候：

from django.conf import settings

毫无疑问，首先会访问django.conf.__init__.py文件。在这里settings是一个lazy object，但是这不是本章的重点，只需要知道当访问settings的时候，真正实例化的是以下这一个Settings类。

class Settings(BaseSettings):
    def __init__(self, settings_module):
        # update this dict from global settings (but only for ALL_CAPS settings)
        for setting in dir(global_settings):
            if setting.isupper():
                setattr(self, setting, getattr(global_settings, setting))
        # store the settings module in case someone later cares
        self.SETTINGS_MODULE = settings_module


        mod = importlib.import_module(self.SETTINGS_MODULE)


        tuple_settings = (
            "INSTALLED_APPS",
            "TEMPLATE_DIRS",
            "LOCALE_PATHS",
        )
        self._explicit_settings = set()
        for setting in dir(mod):
            if setting.isupper():
                setting_value = getattr(mod, setting)
                if (setting in tuple_settings and
                        not isinstance(setting_value, (list, tuple))):
                    raise ImproperlyConfigured("The %s setting must be a list or a tuple. " % setting)
                setattr(self, setting, setting_value)
                self._explicit_settings.add(setting)
                
        if not self.SECRET_KEY:
            raise ImproperlyConfigured("The SECRET_KEY setting must not be empty.")


        if hasattr(time, 'tzset') and self.TIME_ZONE:
            # When we can, attempt to validate the timezone. If we can't find
            # this file, no check happens and it's harmless.
            zoneinfo_root = '/usr/share/zoneinfo'
            if (os.path.exists(zoneinfo_root) and not
                    os.path.exists(os.path.join(zoneinfo_root, *(self.TIME_ZONE.split('/'))))):
                raise ValueError("Incorrect timezone setting: %s" % self.TIME_ZONE)
            # Move the time zone info into os.environ. See ticket #2315 for why
            # we don't do this unconditionally (breaks Windows).
            os.environ['TZ'] = self.TIME_ZONE
            time.tzset()


    def is_overridden(self, setting):
        return setting in self._explicit_settings


    def __repr__(self):
        return '<%(cls)s "%(settings_module)s">' % {
            'cls': self.__class__.__name__,
            'settings_module': self.SETTINGS_MODULE,
        }

在该类的初始化函数的最后，可以看到当USE_TZ=True的时候（即开启Django的时区功能），还需要设置TIME_ZONE。比如，新建一个Django项目，保留默认的时区设置，并启动django shell：

# settings.py
TIME_ZONE = 'UTC'
USE_I18N = True
USE_L10N = True
USE_TZ = True


# python3 manage.py shell
>>> import datetime
>>> datetime.datetime.now()
datetime.datetime(2016, 12, 7, 9, 19, 34, 741124)
>>> datetime.datetime.utcnow()
datetime.datetime(2016, 12, 7, 9, 19, 45, 753843)

默认的Python Shell通过datetime.now返回的应该是当地时间，在这里即中国时区，但是当settings.TIME_ZONE设置为UTC的时候，通过datetime.now返回的就是UTC时间。

可以试试将TIME_ZONE设置成中国时区：

# settings.py
TIME_ZONE = 'Asia/Shanghai'
# python3 manage.py shell
>>> import datetime
>>> datetime.datetime.now()
datetime.datetime(2016, 12, 7, 17, 22, 21, 172761)
>>> datetime.datetime.utcnow()
datetime.datetime(2016, 12, 7, 9, 22, 26, 373080)

此时datetime.now返回的就是中国时区了。当使用timezone.now函数的时候，情况则不一样，在支持时区功能的时候，该函数返回的是一个带有UTC时区信息的aware datetime obeject，即它不受TIME_ZONE变量的影响。

直接看它的源码实现：

def now():
    """
    Returns an aware or naive datetime.datetime, depending on settings.USE_TZ.
    """
    if settings.USE_TZ:
        # timeit shows that datetime.now(tz=utc) is 24% slower
        return datetime.utcnow().replace(tzinfo=utc)
    else:
        return datetime.now()

不支持时区功能，就返回一个受TIME_ZONE影响的naive datetime object。

实践场景

假设现在有这样一个场景，前端通过固定格式提交一个时间字符串供后端的form验证，后端解析得到datetime object之后再通过django orm存储到DatetimeField里面。

Form.DateTimeField

在django关于timezone的官方文档中，已经说明了经过form.DatetimeField返回的在cleaned_data中的时间都是当前时区的aware datetime object。

Time zone aware input in forms¶

When you enable time zone support, Django interprets datetimes entered in forms in the current time zone and returns aware datetime objects in cleaned_data. If the current time zone raises an exception for datetimes that don’t exist or are ambiguous because they fall in a DST transition (the timezones provided by pytz do this), such datetimes will be reported as invalid values.

Models.DatetimeField

在存储时间到MySQL的时候，首先需要知道在Models里面的DatetimeField通过ORM映射到MySQL的时候是什么类型。笔者首先建立了一个Model作为测试：

# models.py
class Time(models.Model):
    now = models.DateTimeField()

# MySQL Tables Schema
+-------+-------------+------+-----+---------+----------------+
| Field | Type        | Null | Key | Default | Extra          |
+-------+-------------+------+-----+---------+----------------+
| id    | int(11)     | NO   | PRI | NULL    | auto_increment |
| now   | datetime(6) | NO   |     | NULL    |                |
+-------+-------------+------+-----+---------+----------------+

可以看到，在MySQL中是通过datetime类型存储Django ORM中的DateTimeField类型，其中datetime类型是不受MySQL的时区设置影响，与timestamp类型不同。因此，如果笔者关闭了时区功能，却向MySQL中存储了一个aware datetime object，就会得到以下报错：

"ValueError: MySQL backend does not support timezone-aware datetimes. "

关于对时区在业务开发中的一些看法

后端应该在数据库统一存储UTC时间并返回UTC时间给前端，前端在发送时间和接收时间的时候要把时间分别从当前时区转换成UTC发送给后端，以及接收后端的UTC时间转换成当地时区。

--End--

推荐阅读

Django基础(32)：按日期与时间字段查询数据及模板中日期时间类型数据的格式化及比较

Django实战: 利用自定义模板标签实现仿CSDN博客月度归档