Django-rest-framework: シリアライザーDateTimeFieldに予期しないタイムゾーン情報があります

スタックオーバーフローについて尋ねたところ、現在のタイムゾーンはユーザーが指定した日時にのみ使用されるという結論に達しました。日時は検証後（つまり、作成または更新後）そのままシリアル化されるためです。 Djangoのドキュメントから、これが意図された動作であるとは信じがたいですが、これはRest FrameworkではなくDjango自体の問題であるため、この問題を閉じます。

こんにちは@tomchristie 、

これはDRFのバグだと思います。
IMHO、DRFの自然な使用法は、djangoテンプレートのような出力として使用することです。
djangoテンプレートでタイムゾーンが正しく表示されているのに、drfシリアライザーがdjangoのタイムゾーン設定を尊重しないのはなぜですか？

やあ、

DatetimeFieldクラスのfields.pyのコードを調べると、Djangoのタイムゾーン設定が内部値（ to_internal_value() ）に対してのみ考慮されていることがわかりました。

私は次のようなモデルシリアライザーを使用しているのを見てきました：

class MyModelSerializer(ModelSerializer):

    class Meta:
        model = MyModel
        depth = 1
        fields = ('some_field', 'my_date_time_field')

フィールドmy_date_time_field （DateTimeFieldだと思います:)）の場合、表現のタイムゾーンはデフォルトではNoneです（ to_representation() ）。

言い換えれば、私が間違っていなければ、Djangoタイムゾーンは値がストレージバックエンドに書き込まれたときにのみ考慮されます。

IMHO to_representation()の戻り値は次のようになると思います。
return self.enforce_timezone(value).strftime(output_format)
Django USE_TZ設定によると。

これに対するプルリクエストを作成します。

チャオ
ヴァレンティノ

@vpistis現在

TIME_ZONE = 'Asia/Kolkata'を設定し、単一の日時フィールドappointmentを持つモデルシリアライザーを作成します。

作成/更新中に、以下を送信します。

{
    "appointment": "2016-12-19T10:00:00"
}

そして戻ってください：

{
    "appointment": "2016-12-19T10:00:00+5:30"
}

ただし、そのオブジェクトを再度取得または一覧表示すると、次のようになります。

{
    "appointment": "2016-12-19T04:30:00Z"
}

作成時にZが指定されていない場合、DRFは、クライアントがTIME_ZONE指定されたタイムゾーンを使用していると見なし、そのタイムゾーンにフォーマットされた時間を返します（最後に+5:30を追加します。クライアントが提供した時間であれば、実際には無効になります）。 将来のアクセスでもそのタイムゾーンにフォーマットされた時刻が返される場合は、おそらくより理にかなっているため、取得/リスト中の応答は作成/更新中と同じでした。

作成/更新中に末尾のZが提供されたときに、構成されたタイムゾーンで時間を返すかどうかという問題もあります。たとえば、次のように送信します。

{
    "appointment": "2016-12-19T04:30:00Z"
}

戻り値：

{
    "appointment": "2016-12-19T10:00:00+5:30"
}

リスト/取得の応答と一貫性のある応答を維持するので、私はこれに賛成です。

もう1つのオプションは、作成/更新中であっても、常にUTC時間を返すことですが、あまり役に立たないことがわかりました。 いずれにせよ、現在の50/50のような状況よりも、一貫したタイムゾーンを持つことが望ましいでしょう。

TIME_ZONE = 'Asia / Kolkata'を設定し、単一の日時フィールドである予定を持つモデルシリアライザーを作成します。

作成/更新中に、以下を送信します。

{{
「予定」：「2016-12-19T10：00：00」
}
そして戻ってください：

{{
"予定"： "2016-12-19T10：00：00 + 5：30"
}
ただし、そのオブジェクトを再度取得または一覧表示すると、次のようになります。

{{
「予定」：「2016-12-19T04：30：00Z」
}

ありがとう@ jonathan-golorryこれは私が実際に見ている正確な動作です。
私の場合、動作は次のようになります（@ jonathan-golorryの例を使用:)）：

デフォルトのDATETIME_FORMATを使用した作成/更新中に、以下を送信します。

{
    "appointment": "2016-12-19T10:00:00"
}

そして戻ってください：

{
    "appointment": "2016-12-19T10:00:00+5:30"
}

そのオブジェクトを再度取得または一覧表示すると、次のようになります。

{
    "appointment": "2016-12-19T10:00:00+5:30"
}

IMHOは、この動作を管理するためのDRF設定である必要があります。たとえば、DateTimeFieldをデフォルトのタイムゾーンで表示するように強制する設定です。

どうもありがとう@tomchristie

異なるアクション間の不一致は、ここで再開するためのクリンチャーです。 そうだとは思いもしませんでした。 オプションにすることもできますが、デフォルトではUTCを使用することを期待しています。

DRF 3.4.6を使用する本番Webアプリの場合、次の回避策で解決しました。
https://github.com/vpistis/django-rest-framework/commit/be62db9080b19998d4de3a1f651a291d691718f6

誰かが次のいずれかを含むプルリクエストを送信したい場合：

• 失敗したテストケースを含むだけ、または...
• テストケース+修正

それは大歓迎です。

テストするコードをいくつか作成しましたが、drfテストケースの使用方法がわかりません。 実行時にタイムゾーンやその他の設定を変更するためにdjango設定を管理する方法がわかりません。
具体的な例やガイドをリンクしてください。

ありがとう

グローバルテスト設定を変更する場合は、ここにあり

テスト中に設定を上書きしようとしている場合は、 override_settingsデコレータを使用できます。

この機能もいただければ幸いです。 標準のDjangoの動作と同様に、 USE_TZ設定を尊重し、値を変換する必要があると思います。

ここでの最初のステップは、現在のテストスイートに追加できる失敗したテストケースを作成することです。
次のステップは、その場合の修正を開始することです:)

やあ、
私にとって、これはこの機能のテストケースです

class TestDateTimeFieldTimeZone(TestCase):
    """
    Valid and invalid values for `DateTimeField`.
    """
    from django.utils import timezone

    valid_inputs = {
        '2001-01-01 13:00': datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone()),
        '2001-01-01T13:00': datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone()),
        '2001-01-01T13:00Z': datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone()),
        datetime.datetime(2001, 1, 1, 13, 00): datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone()),
        datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.UTC()): datetime.datetime(2001, 1, 1, 13, 00,
                                                                                        tzinfo=timezone.get_default_timezone()),
        # Django 1.4 does not support timezone string parsing.
        '2001-01-01T13:00Z': datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone())
    }
    invalid_inputs = {}
    outputs = {
        # This is not simple, for now I suppose TIME_ZONE = "Europe/Rome"
        datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone()): '2001-01-01T13:00:00+01:00',
        datetime.datetime(2001, 1, 1, 13, 00, ): '2001-01-01T13:00:00+01:00',
    }

    field = serializers.DateTimeField()

私のフォークでは、いくつかのトリックを使用して、3.6.2_tz_fixの正しいタイムゾーンで時間を取得します。

私はこの助けを願っています:)

これは閉じているようですが、drf 3.6.3を実行していて、postgresデータベースにこのタイムスタンプ「2017-07-1214：26：00-06」がありますが、postmanを使用してデータを取得すると、この「タイムスタンプ」が取得されます。 ：「2017-07-12T20：26：00Z」。 -06時間追加されているようです。

私のdjango設定では、tzlocalを使用してタイムゾーンTIME_ZONE = str(get_localzone())ます。 したがって、タイムゾーンは起動時に設定されます。

基本的なmodelSerializerを使用しています

class SnapshotSerializer(serializers.ModelSerializer):
    class Meta:
        model = Snapshot
        resource_name = 'snapshot' 
        read_only_fields = ('id',)
        fields = ('id', 'timestamp', 'snapshot')

私は何かが足りないのですか？

閉じていません、まだ開いています:)
表示されている赤い「閉じたボタン」は、参照用です。
...そしてあなたは正しいです、「バグ」はまだそこにあります;（
マイルストーンが3.6.3から3.6.4に変更されました。

ああ、わかりました。 ありがとうございました！

2017年7月12日午後5時10分、「ValentinoPistis」 [email protected]
書きました：

閉じていません、まだ開いています:)
表示されている赤い「閉じたボタン」は、参照用です。
...そしてあなたは正しいです、「バグ」はまだそこにあります;（
マイルストーンが3.6.3から3.6.4に変更されました。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/encode/django-rest-framework/issues/3732#issuecomment-314923582 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AIMBTcx-6PPbi_SOqeLCjeWV1Rb59-Ohks5sNVJ0gaJpZM4G0aRE
。

やあ、

これが元の質問に完全に関連しているかどうかはわかりませんが、 https： //docs.djangoproject.com/en/1.11/ref/utils/#djangoのように、DRFが設定されているタイムゾーンのオーバーライドを尊重する必要があり

ユーザーがタイムゾーンに関連付けられているシステムがあり、APIはナイーブな日時を受け取ります。 これらの日時を現在のユーザーのタイムゾーンに変換できると思いますが、 ../rest_framework/fields.pyがデフォルトのタイムゾーン（つまり、django設定ファイルのタイムゾーン）を適用していることに気付きました。

    def enforce_timezone(self, value):
        field_timezone = getattr(self, 'timezone', self.default_timezone())

        if (field_timezone is not None) and not timezone.is_aware(value):
            try:
                return timezone.make_aware(value, field_timezone)

[...]

    def default_timezone(self):
        return timezone.get_default_timezone() if settings.USE_TZ else None

私の場合のように、アプリケーションがオーバーライドを設定した場合に備えて、これは実際にtimezone.get_current_timezone()を設定として使用する必要がありますか？

こんにちは@RichardForshawは別の問題のようですが、確かに同じ球場です。

期待される動作をカバーする適切なテストケースのセットを取得できれば、ここでPRを確認することは間違いないと思います。

私の最初の考えはそれを超えて、サーバーの構成されたタイムゾーンに依存するのではなく、タイムゾーン情報をAPIに送信することを確認することです。 それを超えて、私はあなたがクライアントの時間をローカライズする準備をする必要があると思う傾向があります。

しかし、はい、ここで対処すべき矛盾があります。 （PRへようこそと言いましたか？🙂）

carltongibson / django-filter＃750はここに関連しているはずです。 私はもともとdjango-filterのタイムゾーン処理をDRFに基づいていたので、750での変更をここで簡単に適用できます。

私の初心者には申し訳ありませんが、ここでの問題は正確には何ですか？ 私のpsqlデータベースのタイムスタンプは正しく、Djangoは正しいタイムゾーンを使用するように設定されています。 タイムスタンプを変換しないようにするDRF設定はありますか？

こんにちは@ michaelaelise—データの例（上部近く）を見ると：

1. 彼らはタイムゾーン情報なしで日時を送信しています。 （これは私の本では悪い動きです。）
2. サーバーはローカルタイムゾーンを適用していて、そのように戻ってきます（この場合は+5:30 ）
3. しかし、後でそれをフェッチすると、UTCとして返されます（ Z 、「Zulu」の場合）。

クライアントがタイムゾーン変換を処理することを前提として、実際の問題ん。 （おそらくNo1を除いて、クライアントのタイムゾーン設定がサーバーと同じであると誰が言うのでしょうか...？）

しかし、それは少し矛盾しています、確かに2と3は同じ形式である必要がありますか？ （クライアントは正しく、どちらかを同等の値として受け入れますが。）

私はこれを閉じる傾向があります。

• ここには論理エラーはありません。
  
  
  
  • これらは同じ時間です： "2016-12-19T10:00:00+5:30"と"2016-12-19T04:30:00Z" —ある程度、彼らがどのように戻ってくるかを気にするのは誰ですか？
  
  
• したがって、それは私が本当に時間を割り当てることを正当化できるものではありません。
• チケットは2年前のもので、誰もPRを提供していません。

PRを見てうれしいですが、これを_未解決の問題_と本当に考えたいかどうかはわかりません。

ああ、この号のスレッドの元の投稿で、「Z」がそれを意味していることに気づいていませんでした。
では、DRFは認識された日時をUTCに変換して、UI /呼び出し元によって処理されますか？
その説明をありがとう。

最後に一つだけ。
異なるタイムゾーンでデバイスをポーリングしているため、「2016-12-19T10：00：00 + 5：30」を返したい場合はどうなりますか。
これは「RETURN_DATETIME_WITH_TIMEZONE」の設定でしょうか？

エッジデバイスでdjango / drfを使用しています。 したがって、挿入されるすべての日時は、エッジデバイスのタイムゾーンが構成されており、postgresフィールドがそのデバイスの日時に対して常に正確であるため、ナイーブであるかどうかは関係ありません。

現在のシナリオのクラウドサーバーは、各デバイスのタイムゾーンを知る必要があります。おそらく、作業をdjango / drfからクラウドアプリにシフトして処理するだけです。

USE_TZを想定すると、DRFはすでにタイムゾーン情報とともに日時を返しています。 だから、それはあなたがそこで必要なことをすでにやっています。

ここでの唯一の問題は、同じDTが1つのタイムゾーンまたは別のタイムゾーンのようにフォーマットされているかどうかです。 （しかし、それらはまだ同じ時間です。）

@carltongibson

ここには論理エラーはありません。
これらは同じ時間です：「2016-12-19T10：00：00 + 5：30」と「2016-12-19T04：30：00Z」—ある程度、彼らがどのように戻ってくるかを気にするのは誰ですか？

私見これが問題です：返された文字列！
私はDjangoタイムゾーン設定を使用しており、すべてのテンプレートは予想どおり正しい時刻"2016-12-19T10:00:00+5:30"返しますが、DRFは返しません。 DRFは"2016-12-19T04:30:00Z"返します。
クライアントに、それは私のREST APIを消費します、それはロジックも、時間変換も日時文字列解釈もありません。
言い換えると、DRF応答からの日時はDjangoテンプレートの「応答」と同じであると期待しています。サーバーはクライアントのすべてのデータを準備し、クライアントはそれのみを表示します。

とにかく、この素晴らしいプロジェクトへのあなたの忍耐、サポート、そしてあなたの素晴らしい仕事に感謝します！

@vpistisここでの私のポイントは、表現された日付が正しいということです。表現だけが期待されていません。 それをネイティブの日付に解析するとすぐに、どの言語でもそれを処理しますが、違いはありません。

ユーザーが日付文字列を日付に解析することを期待しますが、クライアント言語は生の文字列を消費するのではなく、それを提供します。

あなたが生の弦を消費しているなら、あなたの期待はここでは満たされません。 （ただし、そうしないでください。UNIXタイムスタンプを送信した場合を想像してください。これらを未加工で使用する方法はありません。クライアント言語に関係なく、適切なDateオブジェクトに変換してください。）

これについてPRをとることができて本当にうれしいです。 （まだ閉じていません！）

しかし、報告されてからほぼ2年、最初のコメントから9か月が経ちました（あなたの、1年後）。 誰も私たちに失敗したテストケースを与えてくれませんでした。 それは誰にとってもそれほど重要なことではありません。 そのため、時間を割り当てるのは困難です。

（そのため、PRが発生した場合はPRを行うことに基づいて閉鎖する傾向があります）

みなさん、こんにちは。これは＃5408で修正する必要があります。 ブランチをインストールして、すべてが期待どおりに機能していることを確認する時間があれば、それは素晴らしいことです。 ありがとう！

この問題はどういうわけか、再導入されたと思います。

デフォルトのTZをUTCからヨーロッパ/アムステルダムに変更したとき、テストの1つが失敗し、DRFがデフォルトのTZとは異なるものにシリアル化されていることに気付きました。

編集：問題はテスト/工場のセットアップに関連していました。

モデル

class Something(StampedModelMixin):
    MIN_VALUE = 1
    MAX_VALUE = 500

    id = models.BigAutoField(primary_key=True)  # pylint: disable=blacklisted-name
    product_id = models.BigIntegerField(db_index=True)
    start_time = models.DateTimeField()
    end_time = models.DateTimeField()
    percentage = models.IntegerField()
    enabled = models.IntegerField()

工場

class SomethingFactory(factory.django.DjangoModelFactory):
    """ Base Factory to create records for Something

    """
    start_time = factory.Faker('date_time', tzinfo=get_default_timezone())
    end_time = factory.Faker('date_time', tzinfo=get_default_timezone())
    percentage = factory.Faker('random_int', min=1, max=500)
    enabled = factory.Faker('random_element', elements=[0, 1])

    class Meta:  # pylint: disable=missing-docstring
        model = Something

単体テスト

class TestSomething:
    def test__get__empty(self):
        # preparation of data
        series = SeriesFactory.create(product_id=2)
        SomethingFactory.create_batch(3, product_id=1)

        # prepare request params
        url = reverse('series-somethings', kwargs={'pk': series.pk})

        # call the endpoint
        response = self.client.get(url)

        # asserts
        assert response.data == []

    def test__get__single(self):
        # preparation of data
        series = SeriesFactory.create(product_id=1)
        old_somethings = SomethingFactory.create_batch(1, product_id=1)

        # prepare request params
        url = reverse('series-somethings', kwargs={'pk': series.pk})

        # call the endpoint
        response = self.client.get(url)

        # asserts
        assert SomethingSerializer(old_somethings, many=True).data == response.data

見る

class SomethingElseView(APILogMixin, ModelViewSet):
    @action(detail=True, methods=['get'])
    def somethings(self, request, pk=None):
        """ GET endpoint for Somethings

        .. seealso:: :func:`rest_framework.decorators.action`
        """
        otherthings = self.get_object()
        something_qs = Something.objects.all()
        something_qs = something_qs.filter(product_id=otherthings.product_id)
        serializer = self.something_serializer_class(something_qs, many=True)
        return Response(serializer.data)

シリアライザー

class SomethingSerializer(serializers.ModelSerializer):

    class Meta:
        model = Something
        list_serializer_class = SomethingListSerializer
        fields = '__all__'
        extra_kwargs = {
            'percentage': {'min_value': Something.MIN_VALUE,
                           'max_value': Something.MAX_VALUE}
        }
        read_only_fields = ('id',
                            'ts_activated',
                            'ts_created',
                            'ts_updated')

ipdbの結果をテストする

ipdb> old_somethings
[{'product_id': 1, 'start_time': datetime.datetime(2011, 7, 13, 1, 10, 33, tzinfo=<DstTzInfo 'Europe/Amsterdam' LMT+0:20:00 STD>), 'end_time': datetime.datetime(2003, 3, 10, 9, 31, tzinfo=<DstTzInfo 'Europe/Amsterdam' LMT+0:20:00 STD>), 'percentage': 103, 'enabled': 0}]
ipdb> response.data
[OrderedDict([('id', 1), ('ts_created', '2019-02-27 14:16:33'), ('ts_updated', '2019-02-27 14:16:33'), ('product_id', 1), ('start_time', '2011-07-13 02:50:33'), ('end_time', '2003-03-10 10:11:00'), ('percentage', 103), ('enabled', 0)])]

テスト結果

E       AssertionError: assert [OrderedDict(...nabled', 0)])] == [OrderedDict([...nabled', 0)])]
E         At index 0 diff: OrderedDict([('id', 1), ('ts_created', '2019-02-27 14:38:15'), ('ts_updated', '2019-02-27 14:38:15'), ('product_id', 1), ('start_time', '2011-07-13 01:10:33'), ('end_time', '2003-03-10 09:31:00'), ('percentage', 103), ('enabled', 0)]) != OrderedDict([('id', 1), ('ts_created', '2019-02-27 14:38:15'), ('ts_updated', '2019-02-27 14:38:15'), ('product_id', 1), ('start_time', '2011-07-13 02:50:33'), ('end_time', '2003-03-10 10:11:00'), ('percentage', 103), ('enabled', 0)])
E         Full diff:
E         - [OrderedDict([('id', 1), ('ts_created', '2019-02-27 14:38:15'), ('ts_updated', '2019-02-27 14:38:15'), ('product_id', 1), ('start_time', '2011-07-13 01:10:33'), ('end_time', '2003-03-10 09:31:00'), ('percentage', 103), ('enabled', 0)])]
E         ?                                                                                                                                                       ^^^^^^^^^^                          ^^^^^^^^^^^
E         + [OrderedDict([('id', 1), ('ts_created', '2019-02-27 14:38:15'), ('ts_updated', '2019-02-27 14:38:15'), ('product_id', 1), ('start_time', '2011-07-13 02:50:33'), ('end_time', '2003-03-10 10:11:00'), ('percentage', 103), ('enabled', 0)])]
E         ?

スタック：

Django==2.0.10
djangorestframework==3.9.0
factory-boy==2.11.1
Faker==0.8.18
pytz==2018.9

こんにちは@ diegueus9-これをより単純なテストケースに減らすことができますか？ シリアル化された偽のデータとビューの応答データを比較しています。 したがって、実際の期待値が何であるかは明確ではありません。 いくつかの結果をハードコードされた値と比較することをお勧めします。 例えば、

assert SomethingSerializer(old_somethings, many=True).data == {'blah':'blah'}

@rpkilbyご回答ありがとう

    for old_something in old_somethings:
        old_something.refresh_from_db()

以前のコメントを削除する必要がありますか、それとも他の誰かが同じ誤検知を経験した場合に備えてコメントを残す必要がありますか？

こんにちは@ diegueus9 、心配ありません- detailsタグにコードを隠しただけです。