引言
相信使用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),為什麼以下時間函式會得到時間相差較大的結果?
# 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中關於時區的種種內幕,如有不對,敬請指教。
準備
UTC與DST
UTC可以視為一個世界統一的時間,以原子時為基礎,其他時區的時間都是在這個基礎上增加或減少的,比如中國的時區就為UTC+8。
DST(夏時制)則是為了充分利用夏天日照長的特點,充分利用光照節約能源而人為調整時間的一種機制。通過在夏天將時間向前加一小時,使人們早睡早起節約能源。雖然很多西方國家都採用了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
>>>複製程式碼
既然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。
datetime.now簡析
在呼叫datetime.now()的時候時間是如何返回的呢?在官方文件裡只是簡單地說明了now函式返回當前的具體時間,以及可以�指定時區引數,並沒有具體的說明now函式的實現。
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).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時間轉換成當地時區。