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.

Похоже, что эта проблема все еще остается в Celery 4.0.2.
На метку времени стандартного журнала вывода влияет параметр Django TIME_ZONE.

Выпуск № 4006 говорит об обратном. @marvelph это может быть исправлено в текущем мастере.

У меня были проблемы с CELERY_TIMEZONE = 'Europe / Lisbon' и django TIMEZONE = 'Europe / Lisbon' с использованием планировщика ритмов. он неправильно рассчитал бы дату следующего is_due.
В версии pip у меня было отрицательное вычисление, и это сразу же навсегда избавило меня от задач, на текущем мастере у меня было вычисление до 1 часа + время повторения.
установка обоих параметров на «UTC» устраняет проблему.

Мы объединили # 4173 в master . Если вы можете использовать ветку master и проверить, сохраняется ли проблема, было бы здорово, спасибо.

Я тестировал с мастером, пожалуйста, посмотрите последний комментарий здесь https://github.com/celery/celery/issues/4041
По-прежнему существует проблема с часовым поясом сельдерея на последнем мастере, если у меня есть CELERY_TIMEZONE и TIMEZONE для `` Европа / Лиссабон '', ритм сельдерея django планирует следующую задачу на 1 час больше, чем правильное время

В моем проекте для TIME_ZONE и CELERY_TIMEZONE установлено значение Europe / Moscow, но Celery beat по-прежнему использует UTC. Я также пытался переключить настройку CELERY_ENABLE_UTC, но ничего не изменилось. Мое системное время - Европа / Москва, и это меня очень расстраивает.

Такая же проблема здесь (CELERY_TIMEZONE = TIME_ZONE = Europe / Rome) с сельдереем 4.1 и django 1.11.x

• Мои Period_tasks не работают в ожидаемое время. (Я не исправил: /)
• Когда я повторяю задачу с сельдереем, вычисленное ETA неверно (меньше, чем сейчас), поэтому повторная попытка выполняется мгновенно. Для этой проблемы я рассчитал 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 несколько месяцев назад. Я использовал ветку master прикрепленную к be55de622381816d087993f1c7f9afcf7f44ab33 вместо выпуска, чтобы избежать этого, и она работала должным образом.
Итак, отличный вопрос, почему он до сих пор не выпущен? Это непостижимо.

@Jamim У нас есть еще несколько запросов на

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

установить часовой пояс «Азия / Шанхай». Среда выполнения вычисляет правильное время, но при включении повторной попытки эта не вычисляет «+» с опозданием. вот так '' 'ETA: [2018-04-19 11: 14: 53.216361 + 08: 06]' '' '. Не используется только таблица расчетов. Я собираюсь добавить количество секунд к заданному времени . Он работает, а что не идеально? Надеюсь мое утверждение пригодится.

@auvipy
Очевидно, это не должно было закрываться.

Я использую celery==4.1.0 и Django==1.11.6 .

Независимо от того, что я установил для CELERY_TIMEZONE и TIMEZONE , Celery beat использует UTC. Никакая комбинация True и False для CELERY_ENABLE_UTC и USE_TZ имеет значения.

Лучше признать это ошибкой, чем заставить пользователей думать, что она работает.

попробуйте 4.2rc2 и сообщите пожалуйста

Я не могу понять, что происходит с настройками времени в Celery, но я исправил
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

Но задача по-прежнему показывает время как необработанное UTC - 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 всегда использует UTC, когда я установил

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

на v4.3.0 установлен pip и redis, так что проблема решена или нет?