أنا أستخدم كلاهما وهما يعملان بشكل جيد

بعد التحديث إلى الإصدار 4.1.0 من الإصدار 4.0.2 - حصل خطأ مشابه ، لا يعمل برنامج جدولة المهام بشكل صحيح

نفس الشيء هنا ، عندما أخفض إلى 4.0.2 ، فإنه يعمل مرة أخرى.

أعتقد أن هذا الخطأ مرتبط بالمنطقة الزمنية ، عندما أقوم بتغيير المنطقة الزمنية إلى التوقيت العالمي المنسق (UTC) ، فإنه يعمل.

CELERY_TIMEZONE = "التوقيت العالمي المنسق"
CELERY_ENABLE_UTC = صحيح

هل يمكنك إعادة التحقق من الفرع الحالي master ؟

يمكنني تأكيد هذا الخطأ في 4.1.0

في إعداداتي:

CELERY_TIMEZONE = 'Europe/Moscow'

ونعم إنه يعمل بشكل جيد مع:

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = True

نفس المشكلة - لدينا العديد من المشاريع باستخدام ضربات الكرفس ولكن حدث أحدها لتعيين CELERY_TIMEZONE ليكون المنطقة الزمنية للمشروع والتي كانت America / NewYork. استيقظت حرفيًا على 18 مليون رسالة في خادم Rabbit QA لأن العمال لم يتمكنوا من مواكبة المعدل الذي تم تسجيلهم في قائمة الانتظار - مئات في الدقيقة. أدى حذف الإعدادات والسماح للمشروع الافتراضي إلى CELERY_TIMEZONE من لا شيء إلى حل المشكلة أيضًا.

FWIW - لا أعتقد أننا نستخدم DatabaseScheduler. ربما يجب إعادة تسمية اسم القضية؟

matteiusAyumuKasuga ما اذا كان يمكنك تشغيل اختبار مع master فرع للتحقق من الإصلاح، سيكون أمرا رائعا. آسف للقضايا.

مرحبا georgepsarakis !
لقد اختبرت للتو الفرع الرئيسي ولسوء الحظ في الإعداد الخاص بي ، لا تزال المشكلة قائمة.

كذلك هنا!

أهلا،

لدي مشكلة مماثلة. لقد اتبعت تعليمات إعداد django-celery-beat من: http://docs.celeryproject.org/en/latest/userguide/periodic-tasks.html

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = True
CELERY_RESULT_BACKEND = 'django-db'
CELERY_BEAT_SCHEDULER = 'django_celery_beat.schedulers:DatabaseScheduler'

ثم أحدد مهمة دورية:

@periodic_task(run_every=timedelta(seconds=30))
def do_stuff():
   print("HI")

عند بدء دقات الكرفس ، أحصل على الناتج التالي:

$> DJANGO_SETTINGS_MODULE="proj.settings.dev" celery -A proj beat -l info
celery beat v4.1.0 (latentcall) is starting.
__    -    ... __   -        _
LocalTime -> 2017-08-28 15:58:44
Configuration ->
    . broker -> amqp://guest:**<strong i="14">@localhost</strong>:5672//
    . loader -> celery.loaders.app.AppLoader
    . scheduler -> django_celery_beat.schedulers.DatabaseScheduler

    . logfile -> [stderr]@%INFO
    . maxinterval -> 5.00 seconds (5s)
[2017-08-28 15:58:44,425: INFO/MainProcess] Writing entries...
[2017-08-28 15:58:45,629: INFO/MainProcess] DatabaseScheduler: Schedule changed.
[2017-08-28 15:58:45,630: INFO/MainProcess] Writing entries...

المهمة الدورية موجودة في قاعدة البيانات وتم وضع علامة عليها enabled .

ومع ذلك ، لا يتلقى عامل الكرفس أو ينفذ أي مهام دورية:

$> DJANGO_SETTINGS_MODULE="proj.settings.dev" celery -A proj worker -l info -E

 -------------- celery@proj-dev v4.0.2 (latentcall)
---- **** ----- 
--- * ***  * -- Linux-4.4.0-83-generic-x86_64-with-Ubuntu-16.04-xenial 2017-08-28 15:57:42
-- * - **** --- 
- ** ---------- [config]
- ** ---------- .> app:         proj:0x7f89f78faeb8
- ** ---------- .> transport:   amqp://guest:**<strong i="20">@localhost</strong>:5672//
- ** ---------- .> results:     
- *** --- * --- .> concurrency: 1 (prefork)
-- ******* ---- .> task events: ON
--- ***** ----- 
 -------------- [queues]
                .> celery           exchange=celery(direct) key=celery


[tasks]
  . proj.tasks.do_nothgin
  . proj.tasks.do_stuff

[2017-08-28 15:57:42,269: INFO/MainProcess] Connected to amqp://guest:**@127.0.0.1:5672//
[2017-08-28 15:57:42,287: INFO/MainProcess] mingle: searching for neighbors
[2017-08-28 15:57:43,324: INFO/MainProcess] mingle: all alone

برمجة:

celery==4.1.0
django-celery-beat==1.0.1
django-celery-results==1.0.1
Django==1.8.2

نرحب بأي أفكار / مساعدة لحل هذه المشكلة.

أفضل،
سيباستيان

قطعة من الهراء. إنه لا يعمل.

@ mchen-scala أعتقد أن مشاريع برمجيات المصدر المفتوح مخصصة للنقاد التعاوني والموضوعي والبناء. كم عدد سطور الرموز التي وضعتها في قطعة الهراء؟ لدي بالفعل كرفس مع الإيقاع يعمل بشكل مثالي.

لقد قمت ببناء أنظمة أكثر تقدمًا من أي وقت مضى. لقد كتبت أنظمة تشغيل وأنشأت منصات تداول عالية التردد وقاعدة بيانات واسعة النطاق عبر مراكز البيانات. و أكثر من ذلك بكثير.

أسطر من التعليمات البرمجية؟ أنا أنظر فقط إلى الأنظمة التي تعمل. LOC هو للإطارات.

لا بد لي من استخدام الكرفس لأن النظام الذي ورثته يستخدمه. سوف أتخلص منه وأكتب بنفسي بمجرد أن ننتهي من أول توصيل لنا.

بالإضافة إلى مشكلة النبض ، فإن مطالبة الأشخاص باستخدام قفل لضمان الخاصية مرة واحدة على الأكثر في تنفيذ المهمة هي مزحة كبيرة.

التزم بما تجيده ، وهو OSS حيث لا يمكنك الحصول على وظائف ذات رواتب عالية.

@ mchen-scala لم تكتب أبدًا نظامًا معقدًا في حياتك ، ولا يمكنك حتى فهم سياق هذه التذكرة ، وهو أنه في سلسلة Celery 4 توجد بعض الإصدارات حيث لا يتم اتباع CELERY_BEAT_SCHEDULE إذا لم تكن المنطقة الزمنية التوقيت العالمي المنسق.

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

علاوة على ذلك ، mchen-scala ، أنا أشجعك على إيقاف تشغيل الكرفس - لأننا في المقام الأول لا نحتاج إلى مواقفك في مجتمعنا. لدي وظيفة عالية الأجر لأنني قادر على الاستفادة من OSS وتقديم الدعم لإصلاح المشكلات عند ظهورها. أقترح عليك اتباع تعويذة خاصة بك والتمسك بما تجيده ، والذي يبدو أنه يطرح حلولك الخاصة لمشاكل الحلول الحالية ، وكونك رعشة معادية للمجتمع لبقيتنا. Cya!

لقد أشرت إلى السطر الدقيق من الكود الذي يقوم بتحويل التاريخ والوقت المدرك للمنطقة الزمنية الخاصة بي إلى تاريخ ووقت مستقبلي في إزاحة +20 وأنا متأكد من أنه ليس إزاحة منطقة زمنية حقيقية.
2017-10-11 22: 42: 27.041931-04: 00 يتم تحويلها إلى 2017-10-12 22: 42: 27.041931 + 20:00 في السطر في طلب السحب الخاص بي.
على ما يبدو في وضع UTC ، يظل كائن التاريخ والوقت كما هو في هذه المرحلة في الكود. إذن ما سيحدث بعد ذلك هو أن نتيجة الدلتة المتبقية يتم تفسيرها على أنها -1 يوم ، 1: 27: 32.958069 خلف جدول المهام. لذا فهو يرسل المهمة ولا ينام طويلاً لأنه يتأخر دائمًا. إنها تحافظ على تفوق المهام ، دائمًا لأنها تستغرق يومًا واحدًا حتى يحين موعد المهمة.

تم منح العلاقات العامة الخاصة بي تعليقًا على سطر قديم حقيقي من التعليمات البرمجية ، ومع ذلك يبدو أن جميع اختبارات الوحدة اجتازت وقد نجحت في حل هذه المشكلة في الاختبار الخاص بي. البحث من ملاحظات المتعاون.

لقد أظهرت أن هذه مشكلة في Python 2.7 بالإضافة إلى إصدارات Python 3.5 و 3.6. كي لا نقول أنه ليس خطأ في الإصدارات الأخرى ، فهذه فقط تلك التي أعددت بها البيئات.

حاولت الانتقال من عدم استخدام قاعدة البيانات للإيقاع ، إلى استخدام django-celery-beat ... كان اليوم يقرأ في الغالب مشكلات جيثب :(

هل هناك أي شخص آخر لا يعمل على هذا عند استخدام CELERY_TIMEZONE = 'UTC' ؟ أواجه مشكلات في جعله يعمل مع هذه المجموعة أيضًا ..

xeor قد تحتاج أيضًا إلى ضبط CELERY_ENABLE_UTC = True

تكمن المشكلة الفعلية في تمرير التاريخ والوقت إلى الترجمة () في أنه إذا كان لديك منطقة زمنية محلية غير محددة بالتوقيت العالمي المنسق (UTC) لمشروعك ، فإن هذا التاريخ والوقت صحيح بالفعل عند الانتقال إلى الترجمة ثم dt = dt.astimezone (tz) يحول ذلك إلى التاريخ والوقت المستقبلي غير المنطقي مع منطقة زمنية لا معنى لها.

xeor كنت أواجه نفس المشكلة حتى مع الإعدادات التالية:

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = True
CELERY_BEAT_SCHEDULER = 'django_celery_beat.schedulers:DatabaseScheduler'

الآن ، أعلم أن الأمر يبدو سخيفًا ، لكنني أزلت كلاً من الكرفس وجانغو-كرفس ، وقمت بتثبيتهما مرة أخرى مع أحدث إصدار لهما وقد نجح الأمر.

شكرًا .. لقد حاولت مع كل هؤلاء الثلاثة أيضًا ، دون حظ.
سأحاول لاحقًا بإعادة بناء نظيف للبيئة ..

xeor حسنًا ، من المحتمل جدًا ألا تكون هذه المشكلة هي المشكلة التي تواجهها ، على الرغم من أنها ربما تكون كذلك. كانت النصيحة الواردة في هذه البطاقة متسقة لجميع المستخدمين الذين يواجهون هذه المشكلة حتى الآن ، مما أدى إلى خروج قائمة بالمهام المجدولة عن السيطرة وتلك التي تكلف بالمهام وعدم معالجتها بشكل صحيح بسبب ذلك. هل يمكنك وصف مشكلتك المحددة بشكل أكبر حيث لا يبدو أنك تركت الكثير من التفاصيل حول الخطأ (الأخطاء) أو النتيجة غير المتوقعة التي تحصل عليها؟

يسعدني دائمًا المساعدة. فقط بالإشارة إلى أننا واجهنا هذه المشكلة بدون DatabaseScheduler وقمنا بإصلاحها عن طريق تغيير المناطق الزمنية فقط. في الاختبار الذي أجريته ، أوضحت أن ملف الجدول الذي تم إنشاؤه قبل وبعد هذا الخطأ كان متطابقًا ، لذا لا أعتقد أن الخطأ يتعلق بجدول المواعيد بل نوع أوقات البيانات التي يتم تمريرها إلى استدعاء الترجمة ().

وذلك بفضل لرؤساء متابعة!

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

لست متأكدًا مما إذا كان الإعداد الخاص بي هو أي شيء خاص ، لكنني أستخدم عامل الإرساء ، و amqp ، و rabbitmq وجميع أحدث إصدارات حزم الكرفس ثعبان (وليس rabbitmq tho) .. (آسف ، ليس لدي الحماس هنا لذلك أنا يمكن أن تحقق)..

لدي مشكلة مماثلة ، في بعض الأحيان لا يعمل خفق الكرفس (لا يرسل مهمة إلى الوسيط) بالإضافة إلى ذلك ، فإنه يرسل الكثير من المهام في كل 59 دقيقة
لقد قمت بعمل اختبار للتشغيل كل دقيقة

[2017-11-09 20:52:00,052: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:53:00,049: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:54:00,019: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:55:00,027: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:56:00,049: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:57:00,004: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:58:00,045: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:00,032: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:00,035: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:00,037: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:00,044: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
...
[2017-11-09 20:59:59,977: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,979: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,981: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,986: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,989: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,994: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,997: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 21:00:00,000: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 21:01:00,047: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 21:02:00,047: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 21:03:00,053: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)

في الدقيقة 59 ، تبدأ مجموعة من المهام في العمل وعندما يصل الوقت إلى الدقيقة 0 يتم تشغيلها كما هو متوقع مرة أخرى.
ليس لدي أدنى فكرة عن هذا الخطأ ..؟

هذا هو الإعداد الخاص بي في الكرفس 4.1.0

timezone = 'Asia/Seoul'
enable_utc = False

أنا أستخدم ملف ديسيبل للجدول الزمني

لدي هذه المشكلة أيضًا في python 3.6.3 و pytz 2017.3 و django 1.11.7 و celery 4.1.0 و django-celery-beat 1.1.0.

أقوم بمسح قاعدة البيانات أولاً:

#update django_celery_beat_periodictask set last_run_at = NULL;
#select name, last_run_at from django_celery_beat_periodictask;
           name           |          last_run_at          
--------------------------+-------------------------------
celery.backend_cleanup |                                                       

> pipenv run celery beat -A appname -l debug --scheduler django_celery_beat.schedulers:DatabaseScheduler
Loading .env environment variables…
celery beat v4.1.0 (latentcall) is starting.
__    -    ... __   -        _
LocalTime -> 2017-11-30 08:28:58
Configuration ->
    . broker -> amqp://guest:**<strong i="9">@localhost</strong>:5672//
    . loader -> celery.loaders.app.AppLoader
    . scheduler -> django_celery_beat.schedulers.DatabaseScheduler

    . logfile -> [stderr]@%DEBUG
    . maxinterval -> 5.00 seconds (5s)
[2017-11-30 08:28:58,945: DEBUG/MainProcess] Setting default socket timeout to 30
[2017-11-30 08:28:58,946: INFO/MainProcess] beat: Starting...
[2017-11-30 08:28:58,946: DEBUG/MainProcess] DatabaseScheduler: initial read
[2017-11-30 08:28:58,946: INFO/MainProcess] Writing entries...
[2017-11-30 08:28:58,968: DEBUG/MainProcess] DatabaseScheduler: Fetching database schedule
[2017-11-30 08:28:59,068: DEBUG/MainProcess] Current schedule:
<ModelEntry: celery.backend_cleanup celery.backend_cleanup(*[], **{}) <crontab: 0 4 * * * (m/h/d/dM/MY)>>
[2017-11-30 08:28:59,115: INFO/MainProcess] DatabaseScheduler: Schedule changed.
[2017-11-30 08:28:59,115: INFO/MainProcess] Writing entries...
[2017-11-30 08:28:59,115: DEBUG/MainProcess] DatabaseScheduler: Fetching database schedule
[2017-11-30 08:28:59,121: DEBUG/MainProcess] Current schedule:
<ModelEntry: celery.backend_cleanup celery.backend_cleanup(*[], **{}) <crontab: 0 4 * * * (m/h/d/dM/MY)>>
[2017-11-30 08:28:59,122: DEBUG/MainProcess] beat: Ticking with max interval->5.00 seconds
[2017-11-30 08:28:59,138: DEBUG/MainProcess] Start from server, version: 0.9, properties: {'capabilities': {'publisher_confirms': True, 'exchange_exchange_bindings': True, 'basic.nack': True, 'consumer_cancel_notify': True, 'connection.blocked': True, 'consumer_priorities': True, 'authentication_failure_close': True, 'per_consumer_qos': True, 'direct_reply_to': True}, 'cluster_name': 'rabbit<strong i="10">@Jupiter</strong>', 'copyright': 'Copyright (C) 2007-2017 Pivotal Software, Inc.', 'information': 'Licensed under the MPL.  See http://www.rabbitmq.com/', 'platform': 'Erlang/OTP 20.1', 'product': 'RabbitMQ', 'version': '3.6.14'}, mechanisms: [b'AMQPLAIN', b'PLAIN'], locales: ['en_US']
[2017-11-30 08:28:59,152: DEBUG/MainProcess] using channel_id: 1
[2017-11-30 08:28:59,153: DEBUG/MainProcess] Channel open
[2017-11-30 08:28:59,154: DEBUG/MainProcess] beat: Synchronizing schedule...
[2017-11-30 08:28:59,155: INFO/MainProcess] Writing entries...
[2017-11-30 08:28:59,160: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,161: DEBUG/MainProcess] celery.backend_cleanup sent. id->1dd626be-1dea-43ec-b000-ab61fdd33f9d
[2017-11-30 08:28:59,163: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,163: DEBUG/MainProcess] celery.backend_cleanup sent. id->7a9c7d44-e570-4a5a-9803-0a8e5111f035
[2017-11-30 08:28:59,165: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,166: DEBUG/MainProcess] celery.backend_cleanup sent. id->114ee8e1-4b3c-4f43-a632-9a249d7db364
[2017-11-30 08:28:59,167: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,168: DEBUG/MainProcess] celery.backend_cleanup sent. id->5b7f3825-d6c8-43a5-b056-2d567ec2c4df
[2017-11-30 08:28:59,170: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,171: DEBUG/MainProcess] celery.backend_cleanup sent. id->f1bfb936-0dd1-47b6-be10-3763d4446758
[2017-11-30 08:28:59,172: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,173: DEBUG/MainProcess] celery.backend_cleanup sent. id->7a12f2da-3717-45ab-b018-6b4fd7b83982
[2017-11-30 08:28:59,175: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,175: DEBUG/MainProcess] celery.backend_cleanup sent. id->64fbd61d-e80e-4a32-a49d-31ddc7e155c7
[2017-11-30 08:28:59,177: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,179: DEBUG/MainProcess] celery.backend_cleanup sent. id->ff38e88e-e7e8-4436-9724-9c416dde4d72
[2017-11-30 08:28:59,181: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,181: DEBUG/MainProcess] celery.backend_cleanup sent. id->d5116c47-df14-4f3e-a4d1-09087cd1af80
[2017-11-30 08:28:59,183: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
...

وتستمر قائمة الانتظار بالملء بمعدل 600 / ثانية.

# select name, last_run_at from django_celery_beat_periodictask;
           name           |          last_run_at          
--------------------------+-------------------------------
 celery.backend_cleanup   | 2017-11-30 16:40:59.352453-08 

الإعدادات الخاصة بي هي (لقد قمت بتعيين كل ما يمكنني العثور عليه لأن الوثائق غير واضحة للغاية وقديمة في عدة أماكن):

settings.py
CELERY_TIMEZONE = 'Canada/Pacific'
CELERY_ENABLE_UTC=False
USE_TZ = True
TIME_ZONE = 'Canada/Pacific'

celery.py
app = Celery('MyApp')
app.config_from_object('django.conf:settings', namespace='CELERY')
app.conf.timezone = 'Canada/Pacific'
app.conf.enable_utc = False

لذلك من الواضح أن ما يحدث هو أن الكرفس يدير المهمة في الساعة 08: 28: 59-08 ، ولكن بعد ذلك عند تخزين آخر_وقت_وقت ، فإنه لا يزال يضيف 8 ساعات إلى الوقت للحصول على 16: 28: 59-08 قبل تخزينه في DB.

إلقاء نظرة سريعة على الجداول الزمنية. يخبرني بأننا نعيد الدفعة الزمنية أو # ثانية من crontab.is_due ().

ليس لدي المزيد من الوقت لمواصلة البحث هنا ، ولكن من الواضح أن شيئًا ما داخل فئة crontab يحصل على timedelta بين الوقت الحالي والوقت الحالي مع tz replaced (لم يتم تحويله).

سأكون متشككًا جدًا في السطور ذات المناطق الزمنية replace .

حسنًا - إذا كان بإمكان كل شخص لديه هذا الخطأ استنساخ السيد وإعادة اختبار أنه يعمل على حل المشكلة نيابةً عنك. تم دمج العلاقات العامة الخاصة بي في الليلة الماضية وقد تحققت للتو من أنه أصلح الخطأ ولكن سيكون من الجيد الحصول على تأكيد إضافي لذلك لأولئك الذين يستخدمون جدولة قاعدة البيانات أو الخلفيات الخلفية الأخرى. شكرا!

976515108a4357397a3821332e944bb85550dfa2 تطبيق هذا والتحقق