タイムゾーンのサポートが有効な場合、Django は日時情報をデータベースには UTC で保存し、内部ではタイムゾーンを意識した（aware な） datetime オブジェクトを使用します。フォームではそれをエンドユーザーのタイムゾーンに変換して表示します。テンプレートでは デフォルトのタイムゾーン が使われますが、 フィルターやタグ を使うことでエンドユーザーのタイムゾーンに更新できます。
\nこの機能は、ユーザが複数のタイムゾーンを使用しており、またユーザに対して彼らの時計と同じ日時を表示したいときに有用です。
\nあなたのウェブサイトが1つのタイムゾーンでしか利用できない場合でも、データベースにUTCでデータを保存するのはよいことです。主な理由はサマータイム（DST）です。多くの国では、春に時計を進め、秋に時計を戻すサマータイム制度を採用しています。現地時間で作業している場合、年に2回、この移行時にエラーが発生する可能性があります。あなたのブログには関係ないことかもしれませんが、毎年2回、顧客に1時間ずつ過大請求したり過小請求したりするのは問題です。この問題の解決策は、コード内でUTCを使用し、エンドユーザーとのやりとりの時だけローカルタイムを使用することです。
\nタイムゾーンのサポートはデフォルトで有効になっています。無効にするには、設定ファイルで USE_TZ = False を設定してください。
タイムゾーンのサポートには zoneinfo を使います。これは Python 3.9 から Python 標準ライブラリの一部となりました。
特定の問題と格闘している場合は、タイムゾーンの FAQ を参照してください。
\nPython の datetime.datetime のオブジェクトには、タイムゾーン情報を保持するために使える tzinfo 属性があり、これは datetime.tzinfo のサブクラスのインスタンスで表されます。 この属性がセットされオフセットを示すとき、datetime オブジェクトは aware (タイムゾーンを意識した日時) となります。それ以外の場合は naive (タイムゾーンを意識しない素朴な日時) となります。
is_aware() is_naive() を使って、datatime を aware にするか native にするかを決めることもできます。
タイムゾーンのサポートが無効になっている場合、 Django はローカル時間の naive な datetime オブジェクトを使います。多くの場合、これで十分です。このモードでは、現在時刻を取得するには、次のように書きます:
\nimport datetime\n\nnow = datetime.datetime.now()\nタイムゾーンサポートが有効化 (USE_TZ=True ) されているときは、Django は タイムゾーンを認識する (awareな) datetime オブジェクトを使用します。コード内で datetime オブジェクトを作成した場合も、aware となります。このモードでは、上の例は以下のようになります:
from django.utils import timezone\n\nnow = timezone.now()\n後方互換性を維持するため、 USE_TZ が True のときでも、Django は naive な datetime オブジェクトを受け入れます。データベースレイヤがそのようなオブジェクトを受け取ると、デフォルトのタイムゾーン として解釈して aware に変換しようと試み、警告を発します。
残念ながら、夏時間（DST）の移行中には、存在しない日時や曖昧な日時があります。そのため、タイムゾーンサポートが有効な場合は常に aware な日時オブジェクトを作成するべきです。（DST移行中に日時に適用すべきオフセットを指定するために fold 属性を使用する例については、zoneinfo ドキュメントの Using ZoneInfo セクション を参照してください。）
実際には、これはめったに問題になりません。Django はモデルやーフォームでは aware な datetime オブジェクトを渡し、ほとんどの場合、新しい datetime オブジェクトは timedelta 計算を通じて他の日時から作成されます。唯一アプリケーションのコード内でよく作成される datetime は現在の時刻で、timezone.now() は自動的に適切な処理を行います。
デフォルトタイムゾーン は、TIME_ZONE 設定によって定義されるタイムゾーンです。
カレントタイムゾーン は、レンダリングに使われるタイムゾーンです。
\nactivate() を使って、エンドユーザの実際のタイムゾーンに対するカレントタイムゾーンをセットする必要があります。 そうしないと、デフォルトタイムゾーンが使用されます。
カレントタイムゾーンは、翻訳に対する locale に相当します。ただし、Django がユーザのタイムゾーンを自動的に決めるために使える Accept-Language HTTP ヘッダに相当するものはありません。代わりに、Django は タイムゾーン選択関数 を提供しています。これらを使って、あなたにとって有用なタイムゾーン選択ロジックを組み立ててください。
タイムゾーンを気にするほとんどのウェブサイトは、ユーザーにどのタイムゾーンに住んでいるかを尋ね、この情報をユーザーのプロフィールに保存します。匿名ユーザーの場合は、主な視聴者のタイムゾーンまたはUTCを使用します。 zoneinfo.available_timezones() は利用可能なタイムゾーンのセットを提供し、ロケーションからタイムゾーンへのマッピングを構築できます 。
以下は、セッション内にカレントタイムゾーンを保持する例です。(シンプルにするため、全体的にエラー処理を省略しています。)
\n以下のミドルウェアを MIDDLEWARE に追加します:
import zoneinfo\n\nfrom django.utils import timezone\n\n\nclass TimezoneMiddleware:\n def __init__(self, get_response):\n self.get_response = get_response\n\n def __call__(self, request):\n tzname = request.session.get("django_timezone")\n if tzname:\n timezone.activate(zoneinfo.ZoneInfo(tzname))\n else:\n timezone.deactivate()\n return self.get_response(request)\nカレントタイムゾーンをセットできるビューを作成します:
\nfrom django.shortcuts import redirect, render\n\n# Prepare a map of common locations to timezone choices you wish to offer.\ncommon_timezones = {\n "London": "Europe/London",\n "Paris": "Europe/Paris",\n "New York": "America/New_York",\n}\n\n\ndef set_timezone(request):\n if request.method == "POST":\n request.session["django_timezone"] = request.POST["timezone"]\n return redirect("/")\n else:\n return render(request, "template.html", {"timezones": common_timezones})\nこのビューに POST するフォームを template.html に入れます:
{% load tz %}\n{% get_current_timezone as TIME_ZONE %}\n<form action="{% url 'set_timezone' %}" method="POST">\n {% csrf_token %}\n <label for="timezone">Time zone:</label>\n <select name="timezone">\n {% for city, tz in timezones.items %}\n <option value="{{ tz }}"{% if tz == TIME_ZONE %} selected{% endif %}>{{ city }}</option>\n {% endfor %}\n </select>\n <input type="submit" value="Set">\n</form>\nタイムゾーンサポートを有効にしたとき、Django はフォーム内に入力された日時を カレントタイムゾーン で変換し、cleaned_data 内で aware な datetime オブジェクトを返します。
変換されたdatetimeが存在しないか、または夏時間の移行期間中であるためにあいまいな場合は、無効な値として報告されます。
\nタイムゾーンサポートを有効にしているとき、Django はテンプレートでレンダリングする際に aware な datetime オブジェクトを カレントタイムゾーン に変換します。この動作は、 表示形式のローカライズ と非常によく似ています。
\n\n現地時刻への転換は、適切ではないことがあります -- 人手はなくコンピュータに対してアウトプットを生成するときなどです。以下のフィルタやタグ (tz テンプレートタグライブラリによって提供されています) で、タイムゾーンの転換をコントロールできます。
以下のフィルタは、aware と native の日時の両方を受け入れます。転換するために、これらは native な日時はデフォルトタイムゾーンにあると仮定します。これらは常に aware な日時を返します。
\nlocaltimeLink to this heading#単一の値からカレントタイムゾーンへの変換を強制します。
\n例えば次のようにします:
\n{% load tz %}\n\n{{ value|localtime }}\nutcLink to this heading#単一の値から UTC への転換を強制します。
\n例えば次のようにします:
\n{% load tz %}\n\n{{ value|utc }}\ntimezoneLink to this heading#単一の値から指定したタイムゾーンへの転換を強制します。
\n引数は tzinfo サブクラスのインスタンスか、タイムゾーンの名前である必要があります。
例えば次のようにします:
\n{% load tz %}\n\n{{ value|timezone:"Europe/Paris" }}\n以下は、Django がタイムゾーンをサポートする以前に開始したプロジェクトをマイグレーションする方法です。
\nPostgreSQL バックエンドは datetime を timestamp with time zone として保存します。実際には、これが意味するのは、datetime をコネクションのタイムゾーンからストレージ上では UTC に変換して、取得時には UTC からコネクションのタイムゾーンに変換するということです。
結果として、PostgreSQL を使っている場合、 USE_TZ = False と USE_TZ = True を自由に切り替えることができます。データベース接続のタイムゾーンはそれぞれ DATABASE-TIME_ZONE か UTC に設定されるので、Django はどんな場合でも正しい日時を取得できます。データ変換を行う必要はありません。
他のバックエンドは、タイムゾーン情報なしで日時を保持します。USE_TZ = False から USE_TZ = True に切り替えた場合、現地時刻から UTC に転換する必要があります -- あなたの現地時刻に DST がある場合、これは確実に 1 つに決まるわけではありません。
最初のステップは、設定ファイルに USE_TZ = True を追加することです。この時点では、だいたいのことがうまく動くはずです。コード内で naive な datetime オブジェクトを生成した場合、Django は必要に応じて aware にします。
ただし、これらの変換ではDSTの移行が失敗する可能性があります。これは、まだ対ー無ゾーンサポートの利点が完全には得られていないことを意味します。 また、naive な日時と aware な日時を比較することは不可能なため、いくつかの問題に遭遇する可能性があります。 Django はaware な日時を提供するので、モデルやフォームから来た datetime と、コード内に作成した naive な datetime を比較すると例外が発生します。
\nしたがって、第2のステップは、datetime オブジェクトをインスタンス化している部分を aware に変更するため、コードをリファクタリングすることです。 これは段階的に行うことができます。django.utils.timezone は、互換性のための便利なヘルパーをいくつ定義しています now()、is_aware()、is_naive()、make_aware() そして make_naive() です。
最後に、アップグレードが必要なコードを見つけやすくするために、Django は naive な datetime をデータベースに保存しようとすると警告を出します:
\nRuntimeWarning: DateTimeField ModelName.field_name received a naive\ndatetime (2012-01-01 00:00:00) while time zone support is active.\n開発中、以下を設定ファイルに追加することで、これらの警告を例外として発生するように変更し、トラックバックを得ることができます:
\nimport warnings\n\nwarnings.filterwarnings(\n "error",\n r"DateTimeField .* received a naive datetime",\n RuntimeWarning,\n r"django\\.db\\.models\\.fields",\n)\naware な日時をシリアライズするとき、以下のように UTC オフセットが含まれます:
\n"2011-09-01T13:20:30+03:00"\nしかし、naive な日付の場合はそうではありません:
\n"2011-09-01T13:20:30"\nDateTimeField を使ったモデルに対しては、この違いにより、タイムゾーンサポートのありとなし両方に対して動作するフィクスチャを記述することができません。
USE_TZ = False もしくは Django 1.4 以前 で生成されたフィクスチャは、"naive" 形式を使用します。このようなフィクスチャがプロジェクトに含まれる場合、タイムゾーンサポートを有効化した後に、これらをロードする際に RuntimeWarning を参照してください。警告を破棄するには、これらのフィクスチャを "aware" 形式に転換する必要があります。
loaddata と dumpdata でフィクスチャを再生成できます。または、それらが十分に小さい場合、シリアライズされた各日時に TIME_ZONE に一致する UTC オフセットを追加するように編集できます。
複数のタイムゾーンを必要としません。タイムゾーンサポートを有効化するべきですか？
\nはい。タイムゾーンのサポートを有効にすると、 Django はより正確な現地時間のモデルを使います。これにより、夏時間 (DST) の遷移にまつわる微妙で再現不可能なバグを回避できます。
\nタイムゾーンのサポートを有効にすると、Django の aware な datetime を期待しているところで naive な datetime を使っていることが原因のエラーが発生します。このようなエラーはテストを実行するときに現れます。無効な操作を避ける方法をすぐに知ることができるでしょう。
\n一方、タイムゾーンのサポートがないために起こるバグは、予防、診断、修正が非常に困難です。スケジュールされたタスクや datetime 演算を含むものは、年に1度か2度しか発生しない微妙なバグの原因になります。
\nこのような理由から、新しいプロジェクトではタイムゾーンのサポートがデフォルトで有効になっています。
\nタイムゾーンサポートを有効化しました。私は安全ですか？
\nおそらく。DST 関連のバグからは守られるようになりましたが、それでも不用意な変換 ( naive な日時を aware な日時に変更する、およびその逆）ことによって自ら墓穴を掘る可能性があります。
\nアプリケーションが他のシステムに接続する場合、例えばウェブサービスにクエリする場合、datetime が適切に指定されていることを確認してください。datetime を安全に送信するには、その表現に UTC オフセットを含めるか、その値を UTC にする必要があります（あるいはその両方！）。
\n最後に、私たちのカレンダーシステムには興味深いエッジケースがあります。例えば、ある日付から直接1年を引くことはできません:
\n>>> import datetime\n>>> def one_year_before(value): # Wrong example.\n... return value.replace(year=value.year - 1)\n...\n>>> one_year_before(datetime.datetime(2012, 3, 1, 10, 0))\ndatetime.datetime(2011, 3, 1, 10, 0)\n>>> one_year_before(datetime.datetime(2012, 2, 29, 10, 0))\nTraceback (most recent call last):\n...\nValueError: day is out of range for month\nこのような関数を正しく実装するには、2012-02-29から1年を引いた値が2011-02-28なのか、2011-03-01なのかを決める必要があります。
\n現地時刻で日時を保持しているデータベースと、どのようにやり取りすればいいですか？
\nTIME_ZONE オプションを、DATABASES 設定内のデータベースに適したタイムゾーンにセットしてください。
これは、 USE_TZ が True のときに、タイムゾーンをサポートしておらず、 Django が管理していないデータベースに接続するのに便利です。
私のアプリケーションが TypeError: can't compare offset-naive and offset-aware datetimes とともにクラッシュします -- 何がいけませんか？
naive な datetime と aware な datetime を比較して、このエラーを再現してみましょう:
\n>>> from django.utils import timezone\n>>> aware = timezone.now()\n>>> naive = timezone.make_naive(aware)\n>>> naive == aware\nTraceback (most recent call last):\n...\nTypeError: can't compare offset-naive and offset-aware datetimes\nこのエラーに遭遇した場合、あなたのコードはこれら 2 つを比較している可能性が高いです:
\nDjango が提供する datetime -- 例えば、フォームやモデルフィールド から読み込んだ値。タイムゾーンのサポートが有効になっているので、aware です。
あなたのコードによって生成された datetime。これは naive です（そうでなければ、あなたはこれを読んでいないでしょう）。
通常、正しい解決策は、代わりに aware な datetime を使うようにコードを変更することです。
\nUSE_TZ の値とは関係なく動作するようなプラグイン可能なアプリケーションを書いている場合、 django.utils.timezone.now() が役に立つかもしれません。この関数は、 USE_TZ = False の場合は naive な datetime として、 USE_TZ = True の場合は aware な datetime として現在の日時を返します。必要に応じて datetime.timedelta を足したり引いたりすることができます。
多くの RuntimeWarning: DateTimeField received a naive datetime (YYYY-MM-DD HH:MM:SS) while time zone support is active が発生します。 -- これは悪いことですか？
タイムゾーンのサポートが有効になっている場合、データベース層はコードから aware な datetime だけを受け取ることを期待します。この警告は、naive な datetime を受け取ったときに発生します。これは、タイムゾーンをサポートするためのコードの移植が完了していないことを示しています。このプロセスのヒントについては マイグレーションガイド を参照してください。
\n一方、後方互換性のために、datetime はデフォルトのタイムゾーンにあるとみなされます。
\nnow.date() が昨日 (もしくは明日) になります！
常に naive な日時を使用してきた場合、date() メソッドを呼び出すことで日時を日付に変換できると考えているかもしれません。また、date は datetime に非常に似ているが、精度が低いとも考えるでしょう。
タイムゾーンを意識した環境では、どれも正しくありません:
\n>>> import datetime\n>>> import zoneinfo\n>>> paris_tz = zoneinfo.ZoneInfo("Europe/Paris")\n>>> new_york_tz = zoneinfo.ZoneInfo("America/New_York")\n>>> paris = datetime.datetime(2012, 3, 3, 1, 30, tzinfo=paris_tz)\n# This is the correct way to convert between time zones.\n>>> new_york = paris.astimezone(new_york_tz)\n>>> paris == new_york, paris.date() == new_york.date()\n(True, False)\n>>> paris - new_york, paris.date() - new_york.date()\n(datetime.timedelta(0), datetime.timedelta(1))\n>>> paris\ndatetime.datetime(2012, 3, 3, 1, 30, tzinfo=zoneinfo.ZoneInfo(key='Europe/Paris'))\n>>> new_york\ndatetime.datetime(2012, 3, 2, 19, 30, tzinfo=zoneinfo.ZoneInfo(key='America/New_York'))\nこの例が示すように、同じdatetimeでも、それを表現するタイムゾーンによって日付が異なります。しかし、本当の問題はもっと根本的なところにあります。
\ndatetime は 時点 を表します。それは絶対的なもので、何にも依存しません。逆に、日付は カレンダーの概念 です。その境界は日付が扱われるタイムゾーンに依存します。このように、この2つの概念は根本的に異なっており、datetime を date に変換することは決定論的な操作ではありません。
\nこれは実際のところ何を意味するのでしょうか？
\n一般的に、 datetime を date に変換することは避けるべきです。例えば、 date テンプレートフィルタを使うと、datetime の日付部分だけを表示できます。このフィルタは datetime をフォーマットする前にカレントタイムゾーンに変換し、結果が正しく表示されるようにします。
どうしても自分で変換する必要がある場合は、まず datetime が適切なタイムゾーンに変換されていることを確認する必要があります。通常、これはカレントタイムゾーンになります:
\n>>> from django.utils import timezone\n>>> timezone.activate(zoneinfo.ZoneInfo("Asia/Singapore"))\n# For this example, we set the time zone to Singapore, but here's how\n# you would obtain the current time zone in the general case.\n>>> current_tz = timezone.get_current_timezone()\n>>> local = paris.astimezone(current_tz)\n>>> local\ndatetime.datetime(2012, 3, 3, 8, 30, tzinfo=zoneinfo.ZoneInfo(key='Asia/Singapore'))\n>>> local.date()\ndatetime.date(2012, 3, 3)\nエラーが発生しました "Are time zone definitions for your database installed?"
MySQLを使用している場合は、MySQLノートの タイムゾーンの定義 セクションを参照してタイムゾーン定義を読み込んでください。
\n文字列 "2012-02-21 10:28:45" があり、 "Europe/Helsinki" タイムゾーンであることが分かっています。aware な日時に変換するにはどうすればよいですか？
この場合、必要な ZoneInfo インスタンスを作成し、それを naive な datetime に付加する必要があります。
>>> import zoneinfo\n>>> from django.utils.dateparse import parse_datetime\n>>> naive = parse_datetime("2012-02-21 10:28:45")\n>>> naive.replace(tzinfo=zoneinfo.ZoneInfo("Europe/Helsinki"))\ndatetime.datetime(2012, 2, 21, 10, 28, 45, tzinfo=zoneinfo.ZoneInfo(key='Europe/Helsinki'))\nカレントタイムゾーンで現地時刻を取得するにはどうすればよいですか？
\nそうですね。最初に質問させてください。それは本当に必要ですか？
\n人間とやり取りするときだけ、現地時刻を使うべきです。そして、テンプレートレイヤは日時をあなたが選択したタイムゾーンに転換するための フィルタとタグ を提供しています。
\nさらに、Python は認識された datetime を比較する方法を知っており、必要に応じて UTC オフセットを考慮します。すべてのモデルやビューのコードを UTC で書く方がずっと簡単です (そしておそらく速い)。ですから、ほとんどの場合、 django.utils.timezone.now() で返される UTC での datetime で十分です。
ただし、完全のため、カレントタイムゾーンの現地時間が本当に必要な場合は、以下の方法で取得できます:
\n>>> from django.utils import timezone\n>>> timezone.localtime(timezone.now())\ndatetime.datetime(2012, 3, 3, 20, 10, 53, 873365, tzinfo=zoneinfo.ZoneInfo(key='Europe/Paris'))\nこの例では、カレントタイムゾーンは "Europe/Paris" です。
全ての利用可能なタイムゾーンを参照するにはどうすればいいですか？
\nzoneinfo.available_timezones() は、あなたのシステムで利用可能なIANAタイムゾーンの全ての有効なキーを提供します。使用上の注意についてはドキュメントを参照してください。