Django-rest-framework: Serializer DateTimeField memiliki informasi zona waktu yang tidak terduga

Saya bertanya pada stack overflow dan kesimpulannya adalah bahwa zona waktu saat ini hanya digunakan untuk datetime yang disediakan pengguna, karena datetime diserialisasi apa adanya setelah validasi (yaitu setelah membuat atau memperbarui). Dari dokumentasi Django, saya merasa sulit untuk percaya bahwa ini adalah perilaku yang dimaksudkan, tetapi ini adalah masalah dengan Django itu sendiri daripada Kerangka Istirahat, jadi saya akan menutup masalah ini.

Hai @tomchristie ,

Saya pikir ini adalah bug DRF.
IMHO, penggunaan alami DRF adalah menggunakannya sebagai output seperti templating Django.
Dalam templat Django, zona waktu ditampilkan dengan benar, mengapa serializer drf tidak menghormati pengaturan zona waktu Django?

Hai,

melihat ke dalam kode di fields.py di DatetimeField class Saya menemukan bahwa pengaturan zona waktu Django dipertimbangkan dengan baik hanya untuk nilai internal ( to_internal_value() ).

Saya telah melihat bahwa menggunakan serializer model seperti ini:

class MyModelSerializer(ModelSerializer):

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

untuk bidang my_date_time_field (yang menurut saya ini adalah DateTimeField :) ) zona waktu untuk representasi adalah None untuk default ( to_representation() ).

Dengan kata lain, jika saya tidak salah, zona waktu Django dianggap hanya ketika nilainya ditulis ke dalam backend penyimpanan.

IMHO Saya pikir nilai pengembalian to_representation() harus seperti ini:
return self.enforce_timezone(value).strftime(output_format)
menurut pengaturan Django USE_TZ .

Saya menulis permintaan tarik untuk ini.

Ciao
Valentino

@vpistis Akan lebih mudah untuk meninjau ini jika Anda dapat memberikan contoh perilaku API yang saat ini Anda lihat, dan apa yang Anda harapkan untuk dilihat (daripada mendiskusikan aspek implementasi terlebih dahulu)

Setel TIME_ZONE = 'Asia/Kolkata' dan buat serializer model dengan satu bidang datetime, appointment .

Selama membuat/memperbarui, kirim:

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

dan kembali:

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

Tetapi jika Anda mengambil atau membuat daftar objek itu lagi, Anda mendapatkan:

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

Selama pembuatan, jika Z tidak ditentukan, DRF mengasumsikan klien menggunakan zona waktu yang ditentukan oleh TIME_ZONE dan mengembalikan waktu yang diformat ke zona waktu tersebut (dengan menambahkan +5:30 di akhir, yang sebenarnya tidak valid jika itu adalah waktu yang disediakan klien). Mungkin akan lebih masuk akal jika akses di masa mendatang juga mengembalikan waktu yang diformat ke zona waktu itu, sehingga respons selama pengambilan/daftar sama dengan saat membuat/memperbarui.

Ada juga pertanyaan apakah akan mengembalikan waktu dalam zona waktu yang dikonfigurasi ketika Z tambahan disediakan selama pembuatan/pembaruan, sehingga mengirim:

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

kembali:

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

Saya akan mendukung ini, karena menjaga respons tetap konsisten dengan respons untuk daftar/pengambilan.

Pilihan lain sepenuhnya adalah selalu mengembalikan waktu UTC, bahkan selama pembuatan/pembaruan, tetapi menurut saya itu kurang berguna. Either way, memiliki zona waktu yang konsisten akan lebih baik daripada situasi 50/50 yang kita miliki saat ini.

Atur TIME_ZONE = 'Asia/Kolkata' Anda dan buat serializer model dengan satu bidang datetime, janji temu.

Selama membuat/memperbarui, kirim:

{
"janji": "2016-12-19T10:00:00"
}
dan kembali:

{
"janji": "2016-12-19T10:00:00+5:30"
}
Tetapi jika Anda mengambil atau membuat daftar objek itu lagi, Anda mendapatkan:

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

thanx @jonathan-golorry ini adalah perilaku yang sebenarnya saya lihat.
Bagi saya perilakunya harus seperti ini (menggunakan contoh @jonathan-golorry :) ):

Selama membuat/memperbarui dengan DATETIME_FORMAT default, kirim:

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

dan kembali:

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

Jika Anda mengambil atau mencantumkan objek itu lagi , Anda mendapatkan:

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

IMHO mungkin harus menjadi pengaturan DRF untuk mengelola perilaku ini, misalnya, pengaturan untuk memaksa DateTimeField diwakili dengan zona waktu default.

terima kasih banyak

Ketidakkonsistenan antara tindakan yang berbeda adalah penentu untuk pembukaan kembali di sini. Saya tidak menyadari bahwa itu terjadi. Saya berharap kami menggunakan UTC secara default, meskipun kami dapat menjadikannya opsional.

Untuk aplikasi web produksi yang menggunakan DRF 3.4.6, kami telah menyelesaikannya dengan solusi ini:
https://github.com/vpistis/Django-rest-framework/commit/be62db9080b19998d4de3a1f651a291d691718f6

Jika ada yang ingin mengajukan permintaan tarik yang mencakup:

• hanya menyertakan kasus uji yang gagal, atau ...
• kasus uji + perbaikan

itu akan sangat disambut.

Saya telah menulis beberapa kode untuk diuji, tetapi saya tidak yakin bagaimana menggunakan kasus uji drf. Saya tidak tahu bagaimana mengelola pengaturan Django untuk mengubah Zona Waktu dan pengaturan lainnya saat runtime.
Tolong, tautkan saya beberapa contoh atau panduan spesifik.

terima kasih

Jika Anda ingin mengubah setelan pengujian global, ada di sini .

Jika Anda mencoba untuk mengganti pengaturan selama pengujian, Anda dapat menggunakan override_settings decorator .

Juga akan menghargai fitur ini. Saya merasa bahwa pengaturan USE_TZ harus dihormati dan nilainya harus dikonversi, mirip dengan perilaku Django standar.

Langkah pertama di sini adalah menulis kasus uji yang gagal yang dapat kita tambahkan ke rangkaian pengujian saat ini.
Langkah selanjutnya adalah memulai perbaikan untuk kasus itu :)

Hai,
bagi saya ini adalah kasus uji untuk fitur ini

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

Di garpu saya, saya menggunakan beberapa trik untuk mendapatkan waktu di zona waktu yang benar 3.6.2_tz_fix saya .

Saya harap ini membantu :)

Saya melihat ini ditutup tetapi saya menjalankan drf 3.6.3 dan di database postgres saya, saya memiliki stempel waktu ini "2017-07-12 14:26:00-06" tetapi ketika saya mendapatkan data menggunakan tukang pos saya mendapatkan "stempel waktu" ini : "2017-07-12T20:26:00Z". Saya sepertinya menambahkan -06 jam.

Pengaturan Django saya menggunakan tzlocal untuk mengatur zona waktu TIME_ZONE = str(get_localzone()) . Jadi zona waktu diatur saat startup.

Saya menggunakan modelSerializer dasar

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

Apakah saya melewatkan sesuatu?

belum tutup, masih buka :)
"tombol tertutup" merah yang Anda lihat adalah untuk masalah referensi.
... dan Anda benar, "bug" itu masih ada ;(
Tonggak sejarah diubah dari 3.6.3 menjadi 3.6.4.

Oh oke. Terima kasih!

Pada 12 Jul 2017 17:10, "Valentino Pistis" [email protected]
menulis:

belum tutup, masih buka :)
"tombol tertutup" merah yang Anda lihat adalah untuk masalah referensi.
... dan Anda benar, "bug" itu masih ada ;(
Tonggak sejarah diubah dari 3.6.3 menjadi 3.6.4.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/encode/Django-rest-framework/issues/3732#issuecomment-314923582 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AIMBTcx-6PPbi_SOqeLCjeWV1Rb59-Ohks5sNVJ0gaJpZM4G0aRE
.

Hai,

Saya tidak yakin apakah ini benar-benar terkait dengan pertanyaan awal, tetapi apakah DRF harus menghormati penggantian zona waktu apa pun yang ditetapkan, sesuai https://docs.djangoproject.com/en/1.11/ref/utils/#Django. utils.timezone.aktifkan ?

Saya memiliki sistem di mana pengguna saya dikaitkan dengan zona waktu, dan API menerima waktu naif. Saya berharap dapat mengonversi tanggal tersebut menjadi zona waktu pengguna saat ini, tetapi saya perhatikan bahwa ../rest_framework/fields.py menerapkan zona waktu default (yaitu yang dari file pengaturan 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

Haruskah ini benar-benar menggunakan timezone.get_current_timezone() sebagai preferensi jika aplikasi telah menetapkan penggantian, seperti dalam kasus saya?

Hai @RichardForshaw itu sepertinya masalah yang berbeda, tetapi taman bola yang sama tentu saja.

Jika kita bisa mendapatkan serangkaian kasus uji yang layak yang mencakup perilaku yang diharapkan, saya pikir kita pasti akan melihat PR di sini.

Pikiran pertama saya lebih dari itu adalah memastikan Anda mengirim info zona waktu ke API, daripada mengandalkan zona waktu yang dikonfigurasi server. Di luar itu, saya juga cenderung berpikir bahwa Anda perlu bersiap untuk melokalkan waktu pada klien.

Tapi ya, ada inkonsistensi di sini untuk diatasi. (Apakah saya menyebutkan PR Selamat datang? )

carltongibson/Django-filter#750 harus relevan di sini. Saya awalnya berdasarkan penanganan zona waktu Django-filter pada DRF, sehingga perubahan pada 750 dapat dengan mudah diterapkan di sini.

Maaf untuk pemula saya, tetapi apa sebenarnya masalahnya di sini? Stempel waktu dalam database psql saya benar dan Django diatur untuk menggunakan zona waktu yang benar. Apakah ada pengaturan DRF untuk membuatnya tidak mengonversi cap waktu?

Hai @michaelaelise — jika Anda melihat contoh data (dekat bagian atas):

1. Mereka mengirim datetime tanpa info zona waktu. (Ini adalah langkah yang buruk dalam buku saya.)
2. Server menerapkan zona waktu lokalnya dan kembali seperti itu ( +5:30 dalam kasus ini)
3. Tetapi kemudian, ketika Anda mengambilnya, itu kembali sebagai UTC ( Z , untuk "Zulu" saya kira).

Tidak ada masalah nyata dengan asumsi klien Anda akan menangani konversi zona waktu untuk Anda . (Kecuali mungkin No1, karena siapa bilang klien Anda memiliki pengaturan zona waktu yang sama dengan server Anda...?)

Tapi itu sedikit inkonsistensi, pasti 2 dan 3 harus memiliki format yang sama? (Meskipun klien akan, dengan benar, menerima keduanya sebagai nilai yang setara.)

Saya cenderung untuk menutup ini.

• Tidak ada kesalahan logika di sini.
  
  
  
  • Ini adalah waktu yang sama: "2016-12-19T10:00:00+5:30" dan "2016-12-19T04:30:00Z" — sampai batas tertentu, siapa yang peduli bagaimana mereka kembali?
  
  
• Jadi, itu bukan sesuatu yang saya bisa membenarkan mengalokasikan waktu untuk benar-benar.
• Tiketnya berumur 2 tahun dan tidak ada yang menawarkan PR.

Saya senang melihat PR tetapi saya tidak yakin saya ingin benar-benar menganggap ini sebagai _Open Issue_.

Oh, saya tidak menyadari bahwa dalam posting asli saya di utas masalah ini bahwa "Z" berarti itu.
Jadi DRF mengubah datetime sadar ke UTC untuk ditangani oleh UI/penelepon?
Terima kasih atas klarifikasi itu.

Satu hal terakhir.
Bagaimana jika kita ingin "2016-12-19T10:00:00+5:30" ditampilkan karena kita menggunakan perangkat polling di zona waktu yang berbeda.
Mungkinkah ini pengaturan "RETURN_DATETIME_WITH_TIMEZONE"?

Kami menggunakan Django/drf pada perangkat edge. Jadi semua tanggal waktu yang dimasukkan tidak peduli apakah itu naif atau tidak karena zona waktu perangkat tepi dikonfigurasi dan bidang postgres akan selalu akurat untuk tanggal waktu perangkat tersebut.

Server cloud dalam skenario saat ini kemudian perlu mengetahui zona waktu setiap perangkat, mungkin akan, yang hanya menggeser pekerjaan dari Django/drf ke aplikasi cloud untuk ditangani.

Dengan asumsi USE_TZ, DRF sudah mengembalikan waktu tanggal dengan info zona waktu. Jadi itu sudah melakukan apa yang Anda butuhkan di sana.

Satu-satunya masalah di sini adalah apakah DT yang sama diformat seperti dalam satu zona waktu atau lainnya. (Tapi mereka masih waktu yang sama.)

@carltongibson

Tidak ada kesalahan logika di sini.
Ini adalah waktu yang sama: "2016-12-19T10:00:00+5:30" dan "2016-12-19T04:30:00Z" — sampai batas tertentu, siapa yang peduli bagaimana mereka kembali?

IMHO ini masalahnya: string yang dikembalikan!
Saya menggunakan pengaturan zona Waktu Django dan semua templat mengembalikan waktu yang benar "2016-12-19T10:00:00+5:30" seperti yang kami harapkan, tetapi DRF tidak. DRF mengembalikan "2016-12-19T04:30:00Z" .
Ke klien, yang menggunakan api REST saya, tidak ada logika, tidak ada konversi waktu atau interpretasi string datetime.
Dengan kata lain, saya berharap bahwa datetime dari respons DRF identik dengan "respons" Templat Django: server menyiapkan semua data untuk klien dan klien hanya menunjukkannya.

Bagaimanapun, terima kasih banyak atas kesabaran, dukungan, dan kerja hebat Anda untuk proyek fantastis ini!

@vpistis maksud saya di sini adalah bahwa tanggal yang diwakili benar, hanya representasi yang tidak diharapkan. Segera setelah Anda menguraikannya ke Tanggal asli, bagaimanapun bahasa Anda menanganinya, tidak ada perbedaan.

Saya berharap pengguna mengurai string tanggal ke Tanggal, namun bahasa klien mereka menyediakannya, daripada menggunakan string mentah.

Saya menerima jika Anda mengonsumsi string mentah, harapan Anda tidak akan terpenuhi di sini. (Tapi jangan lakukan itu: bayangkan jika kami mengirim stempel waktu UNIX; tidak mungkin Anda akan mengkonsumsinya mentah-mentah. Konversikan ke objek Date yang tepat, apa pun yang ada dalam bahasa klien Anda.)

Saya sangat senang untuk mengambil PR ini. (Saya belum menutupnya!)

Tapi sudah hampir dua tahun sejak dilaporkan dan sembilan bulan sejak komentar pertama (milikmu, setahun kemudian). Tidak ada yang bahkan memberi kami kasus uji yang gagal. Itu tidak bisa begitu penting bagi siapa pun. Karena itu sulit untuk mengalokasikan waktu.

(Karena itu saya cenderung menutupnya dengan alasan bahwa kami akan mengambil PR jika ada yang muncul)

Hai semua, ini harus diperbaiki dengan #5408. Jika Anda punya waktu untuk menginstal cabang dan memverifikasi bahwa semuanya berfungsi seperti yang diharapkan, itu akan luar biasa. Terima kasih!

Saya pikir masalahnya entah bagaimana, diperkenalkan kembali:

Ketika saya mengubah TZ default dari UTC ke Europe/Amsterdam, salah satu tes gagal dan saya perhatikan DRF membuat serial ke sesuatu yang berbeda dari TZ default

edit: masalah terkait dengan pengujian/pengaturan pabrik.

model

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

pabrik

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

tes satuan

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

melihat

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)

Serializer

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

Hasil tes 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)])]

Hasil tes

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         ?

Tumpukan:

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

Hai @diegueus9 - bisakah Anda mengurangi ini menjadi kasus uji yang lebih sederhana? Anda membandingkan data palsu berseri vs data respons tampilan. Jadi tidak jelas berapa nilai yang diharapkan sebenarnya. Saya akan merekomendasikan membandingkan beberapa hasil dengan nilai hardcoded. misalnya,

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

@rpkilby terima kasih atas jawaban Anda. Itu adalah kesalahan saya, masalah dengan tes unit saya adalah saya menggunakan factory-boy/faker untuk itu tanpa menyegarkan dari DB, maka bedanya, saya baru saja menambahkan

    for old_something in old_somethings:
        old_something.refresh_from_db()

Haruskah saya menghapus komentar saya sebelumnya atau haruskah saya membiarkannya jika ada orang lain yang mengalami hal positif palsu yang sama?

Hai @diegueus9 , jangan khawatir - saya baru saja menyembunyikan kode di tag details .