2016-01-29 81 views
8

我看到這篇文章Is Django corrupting timezone-aware DateTimeField when saving it to the Database?,但它專門使用pytz和mysql,以及哪些地方我不使用pytz並使用SQLite(因爲它可能會產生影響)。Django datetimefield timezone aware CET

我有以下型號

class ScheduleItem(models.Model): 
    work_date = models.DateTimeField('Work date') 

我插入數據如下:

from isoweek import Week 
from dateutil import parser 
from django.utils import timezone 

def foo() 
    year = 2016 #hardcoded for example purpose 
    wknr = 2 #hardcoded for example purpose 
    dateObj = parser.parse(Week(year, wknr).day(0).isoformat() + " 00:00:00") 
    print(dateObj) # 2016-01-11 00:00:00 as expected 
    final = timezone.make_aware(dateObj) 
    print(final) # 2016-01-11 00:00:00+01:00 as expected 
    return final 


workdate = foo() 
si = ScheduleItem(work_date=workdate) 
si.save() 

打印報表給我正確的輸出,但有一次我看在數據庫(SQLite的)我看到2016-01-10 23:00:00

我的Django的設置說

TIME_ZONE = 'CET' 
USE_TZ = True 

檢索數據,我得到:

datetime.datetime(2016, 1, 10, 23, 0, tzinfo=<UTC>) 

爲什麼將其存儲在另一種格式的數據,那麼我指定爲什麼,如果Django是設置爲時區知道我會得到一個UTC時區回來?我的意思是插入前DateTime對象說:datetime.datetime(2016, 1, 11, 0, 0, tzinfo=<DstTzInfo 'CET' CET+1:00:00 STD>)

更新 -

我在此期間發現了一個變通的作爲Django文檔here中所描述的數據庫上設置TIME_ZONE。這使我在數據庫中正確的時區/日期,但根據該文件我不應該需要它,因爲我的DB Django在

管理

這使得與存儲日期時間在第三方數據庫進行交互當地時間而不是UTC。爲避免出現DST更改的問題,您不應爲由Django管理的數據庫設置此選項。

它仍然不清楚我爲什麼在數據庫中存儲時,Django的轉換的datetime對象與CET時區爲UTC,但不夠聰明檢索時,其轉換回CET。

回答

4

Django在內部使用UTC時間。 TIME_ZONE將用於「爲您的意見和型號」(https://docs.djangoproject.com/en/1.9/ref/settings/#std:setting-TIME_ZONE

您開始於2016-01-11 00:00 CET,這是2016-01-10 23:00 UTC!您的日期時間已正確保存到數據庫並在以後進行了恢復,因此所有內容都按預期工作。

+0

我現在可以理解並接受Django的ORM負責根據「USE_TZ」和「TIME_ZONE」的組合在數據庫中轉換和存儲UTC日期時間。但是,從同一部分 「所有視圖和模型將自動在此時區運行」 這不會發生。當通過Model/ORM檢索日期時間時,我得到UTC,而不是我設置中指示的CET版本。當然,我可以使用Django的'timezone.localtime()'來轉換我檢索的內容,但這不是重點。它只做了所需操作的一半。 – ixje

+0

該部分可能更清晰一點:顯示面向用戶的信息時使用TIME_ZONE。嘗試使用人性化模板標籤,我相信您會看到CET時間顯示。 – knite

+0

我選擇授予您賞金/答案,因爲它至少回答了問題的一部分,並讓我理解了內部的一部分。爲什麼它不能恢復我知道的日期時間對象可能是Django的設計選擇,可以考慮在問題的範圍之外。 – ixje