我看到這篇文章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。
我現在可以理解並接受Django的ORM負責根據「USE_TZ」和「TIME_ZONE」的組合在數據庫中轉換和存儲UTC日期時間。但是,從同一部分 「所有視圖和模型將自動在此時區運行」 這不會發生。當通過Model/ORM檢索日期時間時,我得到UTC,而不是我設置中指示的CET版本。當然,我可以使用Django的'timezone.localtime()'來轉換我檢索的內容,但這不是重點。它只做了所需操作的一半。 – ixje
該部分可能更清晰一點:顯示面向用戶的信息時使用TIME_ZONE。嘗試使用人性化模板標籤,我相信您會看到CET時間顯示。 – knite
我選擇授予您賞金/答案,因爲它至少回答了問題的一部分,並讓我理解了內部的一部分。爲什麼它不能恢復我知道的日期時間對象可能是Django的設計選擇,可以考慮在問題的範圍之外。 – ixje