Django时区详解

时间 2019-11-16

标签 django 时区详解栏目 Python 繁體版

原文原文链接

引言

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

RuntimeWarning: DateTimeField received a naive datetime while time zone support is active.复制代码

这个错误究竟是什么意思呢？什么是naive datetime object？什么又是aware datetime object？html

在Django配置中若是将settings.TIME_ZONE设置为中国时区（Asia/Shanghai），为何如下时间函数会获得时间相差较大的结果？前端

# 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=<UTC>)复制代码

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

准备

UTC与DST

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

naive datetime object vs aware datetime object

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

>>> import datetime
>>> naive = datetime.datetime.now()
>>> naive.tzinfo
>>>复制代码

既然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=<UTC>)
>>> aware.tzinfo
<UTC>复制代码

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

datetime.now简析

在调用datetime.now()的时候时间是如何返回的呢？在官方文档里只是简单地说明了now函数返回当前的具体时间，以及能够�指定时区参数，并无具体的说明now函数的实现。django

classmethod datetime.now(tz=None)
Return the current local date and time. If optional argument tz is None or not specified, this is like today(), but, if possible, supplies more precision than can be gotten from going through a time.time() timestamp (for example, this may be possible on platforms supplying the C gettimeofday() function).segmentfault

If tz is not None, it must be an instance of a tzinfo subclass, and the current date and time are converted to tz’s time zone. In this case the result is equivalent to tz.fromutc(datetime.utcnow().replace(tzinfo=tz)). See also today(), utcnow().

OK，那么接下来直接从datetime.now()的源码入手吧。

@classmethod
    def now(cls, tz=None):
        "Construct a datetime from time.time() and optional time zone info."
        t = _time.time()
        return cls.fromtimestamp(t, tz)复制代码

你们能够看到datetime.now函数经过time.time()返回了一个时间戳，而后调用了datetime.fromtimestamp()将一个时间戳转化成一个datetime对象。
那么，不一样时区的时间戳会不会不同呢？不，时间戳不会随着时区的改变而改变，时间戳是惟一的，被定义为格林威治时间1970年01月01日00时00分00秒(北京时间1970年01月01日08时00分00秒)起至如今的总秒数。关于时间戳与时间的关系能够参考这一则漫画。

datetime.fromtimestamp

既然时间戳不会随时区改变，那么在fromtimestamp中应该对时间戳的转换作了时区的处理。
直接上源码：

 @classmethod
    def _fromtimestamp(cls, t, utc, tz):
        """Construct a datetime from a POSIX timestamp (like time.time()). A timezone info object may be passed in as well. """
        frac, t = _math.modf(t)
        us = round(frac * 1e6)
        if us >= 1000000:
            t += 1
            us -= 1000000
        elif us < 0:
            t -= 1
            us += 1000000

        converter = _time.gmtime if utc else _time.localtime
        y, m, d, hh, mm, ss, weekday, jday, dst = converter(t)
        ss = min(ss, 59)    # clamp out leap seconds if the platform has them
        return cls(y, m, d, hh, mm, ss, us, tz)

 @classmethod
    def fromtimestamp(cls, t, tz=None):
        """Construct a datetime from a POSIX timestamp (like time.time()). A timezone info object may be passed in as well. """
        _check_tzinfo_arg(tz)

        result = cls._fromtimestamp(t, tz is not None, tz)
        if tz is not None:
            result = tz.fromutc(result)
        return result复制代码

当直接调用datetime.now()的时候，并无传进tz的参数，所以_fromtimestamp中的utc参数为False，因此converter被赋值为time.localtime函数。

time.localtime

localtime函数的使用只须要知道它返回一个九元组表示当前的时区的具体时间便可：

def localtime(seconds=None): # real signature unknown; restored from __doc__
    """
    localtime([seconds]) -> (tm_year,tm_mon,tm_mday,tm_hour,tm_min,
                              tm_sec,tm_wday,tm_yday,tm_isdst)

    Convert seconds since the Epoch to a time tuple expressing local time.
    When 'seconds' is not passed in, convert the current time instead.
    """
    pass复制代码

笔者以为更须要注意的是什么因素影响了time.localtime返回的时区时间，那么，就须要谈及time.tzset函数了。

在Python官方文档中关于time.tzset函数解释以下：

time.tzset()
Resets the time conversion rules used by the library routines. The environment variable TZ specifies how this is done.

Availability: Unix.

Note Although in many cases, changing the TZ environment variable may affect the output of functions like localtime() without calling tzset(), this behavior should not be relied on.
The TZ environment variable should contain no whitespace.

能够看到，一个名为TZ的环境变量的设置会影响localtime的时区时间的返回。（有兴趣的同窗能够去在Unix下执行man tzset，就知道TZ变量是如何影响localtime了）
最后，笔者给出一些测试的例子，因为获取的时间戳不随时间改变，所以直接调用fromtimestamp便可：

>>> from datetime import datetime
>>> from time import time, tzset
>>> china = datetime.fromtimestamp(time())
>>> import os
>>> os.environ['TZ'] = 'UTC'
>>> tzset()
>>> utc = datetime.fromtimestamp(time())
>>> china
datetime.datetime(2016, 12, 7, 16, 3, 34, 453664)
>>> utc
datetime.datetime(2016, 12, 7, 8, 4, 30, 108349)复制代码

以及直接调用localtime的例子：

>>> from time import time, localtime, tzset
>>> import os
>>> china = localtime()
>>> china
time.struct_time(tm_year=2016, tm_mon=12, tm_mday=7, tm_hour=16, tm_min=7, tm_sec=5, tm_wday=2, tm_yday=342, tm_isdst=0)
>>> os.environ['TZ'] = 'UTC'
>>> tzset()
>>> utc = localtime()
>>> utc
time.struct_time(tm_year=2016, tm_mon=12, tm_mday=7, tm_hour=8, tm_min=7, tm_sec=34, tm_wday=2, tm_yday=342, tm_isdst=0)复制代码

（提早剧透：TZ这一个环境变量在Django的时区中发挥了重大的做用）

Django TimeZone

timezone.now() vs datetime.now()

笔者在前面花费了大量的篇幅来说datetime.now函数的原理，而且说起了TZ这一个环境变量，这是由于在Django导入settings的时候也设置了TZ环境变量。

当执行如下语句的时候：

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的时区功能），设置了TZ变量为settings.TIME_ZONE。

OK，知道了TZ变量被设置为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类型不一样。
关于datetime和timestamp类型能够参考这篇文章。

所以，若是笔者关闭了时区功能，却向MySQL中存储了一个aware datetime object，就会获得如下报错：

"ValueError: MySQL backend does not support timezone-aware datetimes. "复制代码

关于对时区在业务开发中的一些见解

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