Celery: CELERY_TIMEZONE y CELERY_ENABLE_UTC no tienen ningún efecto

Las directivas CELERY_TIMEZONE y CELERY_ENABLE_UTC se aplican al apio, no al trabajador.

El inicio de sesión de apio no tiene en cuenta CELERY_ENABLE_UTC, es solo una simple envoltura del módulo de registro de Python.

CELERY_ENABLE_UTC no está habilitado de forma predeterminada porque las personas pueden usar versiones muy antiguas de Django (por debajo de 1.4).
¿Puede darnos un ejemplo?

@thedrow solo para tener en cuenta, deberíamos habilitar UTC de forma predeterminada en octubre, cuando se terminará el soporte de Django 1.4 LTS (https://www.djangoproject.com/download/)

Sí, probablemente deberíamos hacerlo para 3.2.0.

Ahora que revisé la documentación, vi que CELERY_ENABLE_UTC está habilitado de forma predeterminada, así que creo que este error solo está relacionado con el registro.

Cerrando esto, ya que no tenemos los recursos para completar esta tarea.

Puede corregirse en el maestro, veamos si vuelve después de la versión 4.0.

Como nota útil para cualquiera que pueda tropezar con esta discusión, pude ejecutar mis trabajadores de apio en una zona horaria diferente (UTC) que el proyecto Django (EST). Le di a celery un archivo de configuración de Django diferente (es decir, celery_settings), en el que solo importo la configuración original (desde la importación de configuración *) y luego sobreescribo el parámetro TIME_ZONE.

Parece que este problema aún persiste en Celery 4.0.2.
La marca de tiempo del registro de salida estándar se ve afectada por el parámetro TIME_ZONE de Django.

El número 4006 sugiere lo contrario. @marvelph, esto puede estar arreglado en el maestro actual.

Tuve problemas con CELERY_TIMEZONE = 'Europe / Lisbon' y django TIMEZONE = 'Europe / Lisbon' usando el programador de ritmos. calcularía erróneamente las fechas de la próxima fecha de vencimiento.
En la versión pip hice que el cálculo fuera negativo y eso almorzaría las tareas inmediatamente para siempre, en el maestro actual lo hice calcular en 1h + tiempo de repetición.
establecer ambas configuraciones en 'UTC' soluciona el problema.

Fusionamos # 4173 con master . Si puede utilizar la rama master y comprobar si el problema persiste, sería fantástico, gracias.

Probé con el maestro, consulte el último comentario aquí https://github.com/celery/celery/issues/4041
Todavía hay un problema con la zona horaria del apio en el último maestro, si tengo CELERY_TIMEZONE y TIMEZONE en 'Europa / Lisboa', el ritmo del apio django programa la siguiente tarea en 1h más que la hora correcta

Tengo TIME_ZONE y CELERY_TIMEZONE configurados en Europa / Moscú en mi proyecto, pero Celery beat todavía usa UTC. También intenté cambiar la configuración CELERY_ENABLE_UTC pero nada cambió. La hora de mi sistema es Europa / Moscú y esto es realmente frustrante

El mismo problema aquí (CELERY_TIMEZONE = TIME_ZONE = Europe / Rome) con apio 4.1 y django 1.11.x

• Mis tareas_periódicas no funcionan en el momento esperado. (No lo he arreglado: /)
• Cuando vuelvo a intentar una tarea de apio, la ETA calculada es incorrecta (menor que ahora), por lo que el reintento es instantáneo. Para este problema, he calculado el eta pasándolo a mi tarea reintentada, como puede ver aquí (https://github.com/celery/celery/issues/4221#issuecomment-324204504)

Estoy en Work in Progress, si encuentro una mejor solución, escribiré aquí

Tengo el mismo problema que @ madEng84 Django 1.11 y Celery 4.1, el reintento de tareas no funciona con la cuenta regresiva, solo con eta.

Se trata de una absoluta f * ing broma. Todo lo que se supone que debe hacer el apio es una tarea -> ejecutarlo a tiempo. ¿Por qué demonios estos desarrolladores pierden todo su tiempo agregando una característica exótica xyz que a nadie le importa una mierda cuando ni siquiera puede hacer para lo que está diseñado? ¡Santo cielo!

CELERY_TIMEZONE = 'EE.UU. / Este'

Las tareas se ejecutan en un momento completamente incorrecto en 4.1, estaba bien en 3. lo que sea

@expresspotato Si no está contento con el trabajo que hacemos GRATIS, vaya al tenedor de apio.
También puede pagarnos para solucionar sus problemas.
De lo contrario, los derechos propios no son bienvenidos. Considere esta su última advertencia antes de que le prohíba.

Hasta donde yo sé, este problema se solucionó en el maestro hace unos meses. Usé master branch fijada a be55de622381816d087993f1c7f9afcf7f44ab33 en lugar de liberarlo para evitar esto y funcionó como se esperaba.
Entonces, es una gran pregunta ¿por qué todavía no se ha lanzado? Es incomprensible.

@Jamim Tenemos algunas solicitudes de extracción más para fusionar antes de lanzar. Vea el hito.

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

establezca la zona horaria 'Asia / Shanghai'.El tiempo de ejecución calcula la hora correcta, pero cuando el reintento está habilitado, eta no calcula' + 'atrasado. así '' 'ETA: [2018-04-19 11: 14: 53.216361 + 08: 06]' '' '. Solo no se usa la hoja de cálculo. Voy a agregar el número de segundos al tiempo dado . Funciona, pero ¿qué no es perfecto? Espero que mi declaración sea útil.

@auvipy
Es obvio que esto no debería haberse cerrado.

Estoy ejecutando celery==4.1.0 y Django==1.11.6 .

Independientemente de lo que establezca para CELERY_TIMEZONE y TIMEZONE , Celery beat usa UTC. Ninguna combinación de True y False por CELERY_ENABLE_UTC y USE_TZ hace una diferencia.

Sería mejor reconocer que se trata de un error que hacer que los usuarios piensen que funciona.

intente 4.2rc2 e informe por favor

No puedo entender qué está sucediendo con la configuración de tiempo en Apio, pero arreglé
base.py -> ahora
Y ahora informa la hora real para la zona horaria seleccionada 'Europa / Londres', consulte el registro:

[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

Pero la tarea aún muestra la hora sin procesar UTC - 2018-06-22 12: 24: 42.350384

Cambio de prueba:

[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

Así que parece que ahora la configuración de la zona horaria tiene efecto, ¡PERO las tareas todavía están usando una hora UTC!

En primer lugar, esta probablemente debería ser la instancia de datetime.now, no datetime.utcnow (), porque ¿por qué decidiríamos UTC ya como UTC?

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

Ahora me permite establecer la hora de Londres en todas partes:

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

Pero todavía la tarea recibida en tiempos antiguos:

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 si es posible, abra un PR con sus cambios y podemos discutirlo allí.

Puede probar el argumento nowfun en crontab para configurar una zona horaria diferente

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

Tengo el mismo problema que date_done siempre usando UTC cuando he configurado

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

en v4.3.0 instalado por pip y redis, entonces el problema está solucionado o no?