Celery: CELERY_TIMEZONE و CELERY_ENABLE_UTC ليس لهما تأثير

تعمل التوجيهات CELERY_TIMEZONE و CELERY_ENABLE_UTC مع ضربات الكرفس ، وليس العامل.

لا يأخذ تسجيل الدخول إلى الكرفس في الاعتبار CELERY_ENABLE_UTC ، إنه مجرد غلاف بسيط لوحدة تسجيل Python.

لم يتم تمكين CELERY_ENABLE_UTC افتراضيًا لأن الأشخاص قد يستخدمون إصدارات قديمة جدًا من Django (أقل من 1.4).
هل يمكنك إعطاء مثال؟

thedrow للإشارة فقط ، يجب علينا تمكين UTC افتراضيًا في أكتوبر ، عندما ينتهي دعم Django 1.4 LTS (https://www.djangoproject.com/download/)

نعم ربما يجب أن نفعل ذلك من أجل 3.2.0.

الآن بعد أن راجعت الوثائق ، رأيت أنه تم تمكين CELERY_ENABLE_UTC افتراضيًا لذلك أعتقد أن هذا الخطأ مرتبط فقط بالتسجيل.

إغلاق هذا ، لأننا لا نملك الموارد لإكمال هذه المهمة.

يمكن إصلاحه بشكل رئيسي ، دعنا نرى ما إذا كان سيعود بعد الإصدار 4.0.

كملاحظة مفيدة لأي شخص قد يتعثر في هذه المناقشة ، تمكنت من تشغيل عمال الكرفس لدي في منطقة زمنية مختلفة (UTC) عن مشروع Django (EST). أعطيت الكرفس ملف إعدادات Django مختلفًا (مثل celery_settings) ، حيث قمت فقط باستيراد الإعدادات الأصلية (من استيراد الإعدادات *) ثم الكتابة فوق المعلمة TIME_ZONE.

يبدو أن هذه المشكلة لا تزال قائمة في الإصدار 4.0.2 من الكرفس.
الطابع الزمني لسجل الإخراج القياسي يتأثر بمعامل Django TIME_ZONE.

تشير المشكلة رقم 4006 إلى عكس ذلك. marvelph قد يتم إصلاح هذا في الرئيسي الحالي.

واجهت مشاكل مع CELERY_TIMEZONE = 'Europe / Lisbon' و django TIMEZONE = 'Europe / Lisbon' باستخدام منظم الإيقاع. من شأنه أن يحسب بشكل خاطئ تاريخ تاريخ الاستحقاق التالي.
في إصدار النقطة ، كان الحساب سالبًا وهذا من شأنه أن يبدأ المهام فورًا إلى الأبد ، في المعلم الحالي كنت أحسبه إلى ساعة واحدة + وقت التكرار.
يؤدي ضبط كلا الإعدادين على "UTC" إلى حل المشكلة.

دمجنا # 4173 بـ master . إذا كان بإمكانك استخدام الفرع master وتحقق مما إذا كانت المشكلة لا تزال قائمة ، فسيكون ذلك رائعًا ، شكرًا.

لقد اختبرت مع السيد ، يرجى الاطلاع على أحدث تعليق هنا https://github.com/celery/celery/issues/4041
لا تزال هناك مشكلة في المنطقة الزمنية للكرفس على أحدث معلم ، إذا كان لدي كل من CELERY_TIMEZONE و TIMEZONE إلى "أوروبا / لشبونة" ، فإن دق الكرفس django يحدد موعد المهمة التالية إلى ساعة واحدة أكثر من الوقت الصحيح

تم تعيين كل من TIME_ZONE و CELERY_TIMEZONE على Europe / Moscow في مشروعي ولكن لا يزال Celery beat يستخدم التوقيت العالمي المنسق. لقد حاولت أيضًا تبديل إعداد CELERY_ENABLE_UTC ولكن لم يتغير شيء. وقت نظامي هو أوروبا / موسكو وهذا أمر محبط حقًا

نفس المشكلة هنا (CELERY_TIMEZONE = TIME_ZONE = Europe / Rome) مع الكرفس 4.1 و django 1.11.x

• لا تعمل مهامي الدورية في الوقت المتوقع. (لم أصلحه: /)
• عند إعادة محاولة مهمة كرفس ، يكون الوقت المقدر للوصول المحسوب خاطئًا (أقل من الآن) لذا فإن إعادة المحاولة تكون فورية. بالنسبة لهذه المشكلة ، قمت بحساب eta بتمريرها إلى مهمتي المعاد المحاولة ، كما ترون هنا (https://github.com/celery/celery/issues/4221#issuecomment-324204504)

أنا في طور التقدم ، إذا وجدت حلاً أفضل ، سأكتب هنا

لدي نفس المشكلة مثل @ madEng84 Django 1.11 و Celery 4.1 ، إعادة محاولة المهام لا تعمل مع العد التنازلي ، فقط مع eta.

هذا هو و المطلقة * جي نكتة. كل ما يفترض أن يقوم به الكرفس هو مهمة -> تشغيله في الوقت المحدد. لماذا بحق الجحيم يضيع هؤلاء المطورون كل وقتهم في إضافة ميزة غريبة xyz لا أحد يهتم بها عندما لا يتمكن حتى من فعل ما تم تصميمه من أجله! تبا!

CELERY_TIMEZONE = "أمريكي / شرقي"

تعمل المهام في الوقت الخطأ تمامًا في 4.1 ، ولا بأس في العودة في 3. أيا كان

expresspotato إذا لم تكن سعيدًا بالعمل الذي نقوم به مجانًا ، فانتقل إلى شوكة الكرفس.
يمكنك أيضًا أن تدفع لنا لإصلاح مشاكلك.
وإلا فإن الاستحقاق الذاتي غير مرحب به. اعتبر هذا آخر تحذير لك قبل أن أحظرك.

بقدر ما أعرف ، تم إصلاح هذه المشكلة في الماجستير قبل بضعة أشهر. لقد استخدمت فرع master مثبتًا ليكون be55de622381816d087993f1c7f9afcf7f44ab33 بدلاً من الإصدار لتجنب ذلك وعمل كما هو متوقع.
إذن ، إنه سؤال رائع لماذا لم يتم إصداره بعد؟ انها غير مفهومة.

Jamim لدينا عدد قليل من طلبات السحب الإصدار . انظر المعلم.

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

تعيين المنطقة الزمنية "Asia / Shanghai". يحسب وقت التشغيل الوقت الصحيح ، ولكن عند تمكين إعادة المحاولة ، لا تحسب "+" متأخرًا. مثل هذا '' 'ETA: [2018-04-19 11: 14: 53.216361 + 08: 06]' '' '. لا يتم استخدام ورقة الحساب فقط. سأضيف عدد الثواني إلى الوقت المحدد . يعمل ، ولكن ما هو غير مثالي ، آمل أن يكون بياني مفيدًا.

تضمين التغريدة
من الواضح أن هذا لم يكن يجب إغلاقه.

أنا أدير celery==4.1.0 و Django==1.11.6 .

بغض النظر عما قمت بتعيينه لـ CELERY_TIMEZONE و TIMEZONE ، فإن ضربات الكرفس تستخدم التوقيت العالمي المنسق. لا يوجد فرق بين True و False لـ CELERY_ENABLE_UTC و USE_TZ .

سيكون من الأفضل الاعتراف بأن هذا خطأ بدلاً من جعل المستخدمين يعتقدون أنه يعمل.

حاول 4.2rc2 والإبلاغ من فضلك

لا أستطيع أن أفهم ما يحدث مع إعدادات الوقت في الكرفس ، لكنني أصلحت
base.py -> الآن
والآن يُبلغ عن الوقت الفعلي للمنطقة الزمنية المحددة "أوروبا / لندن" ، راجع السجل:

[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

لكن المهمة لا تزال تظهر الوقت بالتوقيت العالمي المنسق - 2018-06-22 12:24: 42.350384

تغيير الاختبار:

[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

لذلك يبدو الآن أن إعدادات المنطقة الزمنية لها تأثير ، ولكن المهام لا تزال تستخدم التوقيت العالمي المنسق (UTC)!

أولاً ، ربما يجب أن يكون هذا مثال datetime.now ، وليس datetime.utcnow () ، فلماذا نقرر UTC بالفعل UTC؟

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

يتيح لي الآن ضبط توقيت لندن في كل مكان:

<=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

ولكن لا تزال المهمة المستلمة في وقت أقدم:

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 إن أمكن ، يرجى فتح العلاقات العامة مع التغييرات التي

يمكنك تجربة الوسيطة nowfun في crontab لتعيين منطقة زمنية مختلفة

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

لدي نفس المشكلة أن date_done يستخدم دائمًا التوقيت العالمي المنسق عند تعيينه

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

على v4.3.0 مثبتة بواسطة pip و redis ، لذلك تم إصلاح المشكلة أم لا؟