Celery: CELERY_TIMEZONE dan CELERY_ENABLE_UTC tidak berpengaruh

Arahan CELERY_TIMEZONE dan CELERY_ENABLE_UTC bekerja untuk irama seledri, bukan pekerja.

Logging di seledri tidak memperhitungkan CELERY_ENABLE_UTC, itu hanya pembungkus sederhana untuk modul logging python.

CELERY_ENABLE_UTC tidak diaktifkan secara bawaan karena orang mungkin menggunakan versi Django yang sangat lama (di bawah 1.4).
Bisakah Anda memberikan contoh?

@thedrow hanya untuk mencatat, kita harus mengaktifkan UTC secara default pada bulan Oktober, ketika dukungan Django 1.4 LTS akan diakhiri (https://www.djangoproject.com/download/)

Ya, kami mungkin harus melakukannya untuk 3.2.0.

Sekarang setelah saya memeriksa dokumentasi, saya melihat bahwa CELERY_ENABLE_UTC diaktifkan secara default jadi saya pikir bug ini hanya terkait dengan logging.

Menutup ini, karena kami tidak memiliki sumber daya untuk menyelesaikan tugas ini.

Mungkin diperbaiki di master, mari kita lihat apakah kembali setelah rilis 4.0.

Sebagai catatan yang bermanfaat bagi siapa saja yang mungkin tersandung pada diskusi ini, saya dapat menjalankan pekerja seledri saya pada zona waktu yang berbeda (UTC) dari proyek Django (EST). Saya memberi seledri file pengaturan Django yang berbeda (yaitu celery_settings), di mana saya hanya mengimpor pengaturan asli (dari pengaturan impor *) dan kemudian menimpa parameter TIME_ZONE.

Tampaknya masalah ini masih ada di Celery 4.0.2.
Cap waktu dari log keluaran standar dipengaruhi oleh parameter TIME_ZONE Django.

Masalah # 4006 menyarankan sebaliknya. @marvelph ini dapat diperbaiki di master saat ini.

Saya punya masalah dengan CELERY_TIMEZONE = 'Europe / Lisbon' dan django TIMEZONE = 'Europe / Lisbon' menggunakan beat scheduler. itu akan salah menghitung tanggal tanggal is_due berikutnya.
Pada versi pip saya memiliki perhitungan menjadi negatif dan itu akan makan siang tugas untuk selamanya, pada master saat ini saya menghitungnya untuk 1 jam + waktu pengulangan.
mengatur kedua pengaturan ke 'UTC' memperbaiki masalah.

Kami menggabungkan # 4173 menjadi master . Jika Anda dapat menggunakan cabang master dan memeriksa apakah masalahnya tetap ada, alangkah baiknya, terima kasih.

Saya menguji dengan master, silakan lihat komentar terbaru di sini https://github.com/celery/celery/issues/4041
Masih ada masalah dengan zona waktu seledri pada master terbaru, jika saya memiliki CELERY_TIMEZONE dan TIMEZONE ke 'Eropa / Lisbon', seledri django menjadwalkan tugas berikutnya menjadi 1 jam lebih banyak dari waktu yang benar

Saya menyetel TIME_ZONE dan CELERY_TIMEZONE ke Eropa / Moskow dalam proyek saya, tetapi Celery beat masih menggunakan UTC. Saya juga mencoba mengalihkan setelan CELERY_ENABLE_UTC tetapi tidak ada yang berubah. Waktu sistem saya adalah Eropa / Moskow dan ini benar-benar membuat frustrasi

Masalah yang sama di sini (CELERY_TIMEZONE = TIME_ZONE = Eropa / Roma) dengan seledri 4.1 dan django 1.11.x

• Tugas_ periodik saya tidak bekerja pada waktu yang diharapkan. (Saya belum memperbaikinya: /)
• Ketika saya mencoba lagi tugas seledri, ETA yang dihitung salah (lebih rendah dari sekarang) jadi coba lagi seketika. Untuk masalah ini saya telah menghitung eta yang meneruskannya ke tugas coba saya, seperti yang Anda lihat di sini (https://github.com/celery/celery/issues/4221#issuecomment-324204504)

Saya sedang dalam Proses, jika saya menemukan solusi yang lebih baik, saya akan menulis di sini

Saya memiliki masalah yang sama dengan @ madEng84 Django 1.11 dan Celery 4.1,

Ini adalah f mutlak * ing lelucon. Semua seledri seharusnya melakukan tugas -> menjalankannya tepat waktu. Mengapa para pengembang ini membuang-buang waktu mereka menambahkan fitur eksotis xyz yang tidak ada yang peduli ketika ia bahkan tidak dapat melakukan apa yang dirancang untuk itu! Sialan!

CELERY_TIMEZONE = 'AS / Timur'

Tugas dijalankan sepenuhnya pada waktu yang salah di 4.1, baik-baik saja di 3. apa pun

@expresspotato Jika Anda tidak senang dengan pekerjaan yang kami lakukan GRATIS, gunakan seledri garpu.
Anda juga dapat membayar kami untuk memperbaiki masalah Anda.
Jika tidak, hak milik sendiri tidak diterima. Anggap ini peringatan terakhir Anda sebelum saya melarang Anda.

Sejauh yang saya tahu masalah ini telah diperbaiki di master beberapa bulan yang lalu. Saya menggunakan master cabang yang disematkan ke be55de622381816d087993f1c7f9afcf7f44ab33 alih-alih rilis untuk menghindari ini dan berfungsi seperti yang diharapkan.
Jadi, ini pertanyaan bagus mengapa masih belum dirilis? Itu tidak bisa dimengerti.

@Jamim Kami memiliki beberapa permintaan tarik lagi untuk digabungkan sebelum merilis. Lihat pencapaiannya.

https://github.com/celery/celery/commit/be55de622381816d087993f1c7f9afcf7f44ab33

setel zona waktu 'Asia / Shanghai'. Runtime menghitung waktu yang benar, tetapi Ketika coba lagi diaktifkan eta tidak menghitung '+' di belakang waktu. seperti ini '' 'ETA: [2018-04-19 11: 14: 53.216361 + 08: 06]' '". Hanya lembar perhitungan yang tidak digunakan. Saya akan menambahkan jumlah detik ke waktu yang ditentukan . Dia bekerja, Tapi apa yang tidak sempurna? Semoga pernyataan saya bermanfaat.

@vipy
Jelas ini seharusnya tidak ditutup.

Saya menjalankan celery==4.1.0 dan Django==1.11.6 .

Terlepas dari apa yang saya tetapkan untuk CELERY_TIMEZONE dan TIMEZONE , Celery beat menggunakan UTC. Tidak ada kombinasi True dan False untuk CELERY_ENABLE_UTC dan USE_TZ membuat perbedaan.

Akan lebih baik untuk mengakui bug ini daripada membuat pengguna berpikir itu berfungsi.

coba 4.2rc2 dan laporkan

Saya tidak mengerti apa yang terjadi dengan pengaturan waktu di Celery, tapi saya memperbaikinya
base.py -> sekarang
Dan sekarang ini melaporkan waktu aktual untuk zona waktu yang dipilih 'Eropa / London', lihat log:

[2018-06-22 13:24:37,338: ERROR/MainProcess] <=Celery App Base=> now -> now_in_utc                      2018-06-22 12:24:37.336361+00:00
[2018-06-22 13:24:37,338: INFO/MainProcess] <=Celery App Base=> now -> self.timezone                    Europe/London
[2018-06-22 13:24:37,338: ERROR/MainProcess] <=Celery App Base=> now -> now_in_utc.astimezone(self.timezone)                            2018-06-22 13:24:37.336361+01:00
[2018-06-22 13:24:37,338: ERROR/MainProcess] <=Celery Schedules=> now -> self.app.now() 2018-06-22 13:24:37.336361+01:00
[2018-06-22 13:24:37,338: ERROR/MainProcess] <=Utils Time=> remaining -> now 2018-06-22 13:24:37.338674+01:00
[2018-06-22 13:24:42,349: ERROR/MainProcess] <=Celery Schedules=> now -> self.nowfun() 2018-06-22 13:24:42.349524+01:00

Tetapi tugas masih menunjukkan waktu sebagai UTC mentah - 2018-06-22 12: 24: 42.350384

Perubahan tes:

[2018-06-22 13:40:30,568: ERROR/MainProcess] <=Celery App Base=> timezone_func conf.timezone: Europe/Kiev
[2018-06-22 13:40:30,569: ERROR/MainProcess] <=Celery App Base=> timezone_func timezone.get_timezone(conf.timezone): Europe/Kiev

[2018-06-22 13:40:30,603: ERROR/MainProcess] <=Celery App Base=> now -> now_in_utc.astimezone(self.timezone) 1                          2018-06-22 15:40:30.600489+03:00
[2018-06-22 13:40:30,603: ERROR/MainProcess] <=Celery Schedules=> now -> self.app.now() 2018-06-22 15:40:30.600489+03:00
[2018-06-22 13:40:30,604: ERROR/MainProcess] <=Utils Time=> remaining -> now 2018-06-22 15:40:30.603985+03:00
[2018-06-22 13:40:30,604: ERROR/MainProcess] <=Celery Schedules=> now -> self.nowfun() 2018-06-22 15:40:30.604436+03:00

Jadi sepertinya sekarang pengaturan zona waktu berpengaruh, TAPI tugas masih menggunakan waktu UTC!

Pertama, ini mungkin harus berupa instance datetime.now, bukan datetime.utcnow (), karena mengapa kita memutuskan untuk UTC sudah menjadi UTC?

def to_utc(dt):
    """Convert naive :class:`~datetime.datetime` to UTC."""
    return make_aware(dt, timezone.utc)

Sekarang memungkinkan saya untuk mengatur waktu London di mana-mana:

<=Celery App Base=> timezone_func conf.timezone: Europe/London
<=Celery App Base=> timezone_func timezone.get_timezone(conf.timezone): Europe/London
<=Celery Schedules=> now -> self.nowfun() 2018-06-22 14:11:03.625825+01:00
<=Utils Time=> to_utc -> What is dt_utc: 2018-06-22 14:11:03.626616
<=Utils Time=> remaining -> now 2018-06-22 14:11:03.629900+01:00
<=Celery Schedules=> now -> self.nowfun() 2018-06-22 14:11:03.630299+01:00

<=Utils Time=> make_aware -> _localize(dt, is_dst=None) 2018-06-22 14:11:03.630514+00:00
<=Utils Time=> to_utc -> make_aware(dt_utc, timezone.utc): 2018-06-22 14:11:03.630514+00:00
<=Utils Time=> make_aware -> What is dt: 2018-06-22 14:11:03.630514

Tapi tugas masih diterima di waktu yang lebih lama:

Received | 2018-06-22 13:05:02.712443 UTC
-- | --
Sent | 2018-06-22 13:05:02.707066 UTC
Started | 2018-06-22 13:05:02.716835 UTC
Succeeded | 2018-06-22 13:05:03.029372 UTC
Retries | 0
Timestamp | 2018-06-22 13:05:03.029372 UTC

@trianglesis jika memungkinkan, silakan buka PR dengan perubahan Anda dan kami dapat mendiskusikannya di sana.

Anda dapat mencoba argumen nowfun di crontab untuk menyetel zona waktu yang berbeda

https://stackoverflow.com/questions/21827290/celery-beat-different-time-zone-per-task

Saya memiliki masalah yang sama bahwa date_done selalu menggunakan UTC saat saya menyetelnya

cel_app.conf.timezone = 'Asia/Shanghai'
cel_app.conf.enable_utc = True

pada v4.3.0 diinstal oleh pip dan redis, jadi masalahnya sudah diperbaiki atau tidak?