8

この投稿を見ました データベースに保存すると、Djangoはタイムゾーン対応のDateTimeFieldを破損していますか? しかし、特に pytz と mysql を使用しており、pytz を使用せずに SQLite を使用している場合はそうではありません (影響がある場合に備えて)。

私は次のモデルを持っています

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()

printステートメントは正しい出力を提供しますが、データベース（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(2016, 1, 11, 0, 0, tzinfo=<DstTzInfo 'CET' CET+1:00:00 STD>)

更新-

ここTIME_ZONEで Django のドキュメントに記載されているようにデータベースを 設定することで、その間に回避策を見つけました。これにより、データベースの正しいタイムゾーン/日付が得られますが、そのドキュメントによると、DBはDjango によって管理されているため、必要ありません。

これにより、日時を UTC ではなく現地時間で保存するサードパーティ データベースとのやり取りが可能になります。DST の変更に関する問題を回避するには、Django によって管理されるデータベースに対してこのオプションを設定しないでください。

Djangoがデータベースに保存するときに CET タイムゾーンの datetime オブジェクトを UTC に変換する理由はまだ不明ですが、取得時に CET に戻すほどスマートではありません。

4

1 に答える 1