Celery: CELERY_TIMEZONE et CELERY_ENABLE_UTC n'ont aucun effet

Les directives CELERY_TIMEZONE et CELERY_ENABLE_UTC sont travaillées pour le battement de céleri, pas pour le travailleur.

La journalisation dans céleri ne prend pas en compte CELERY_ENABLE_UTC, c'est juste un simple module de journalisation wrapper vers python.

CELERY_ENABLE_UTC n'est pas activé par défaut car les utilisateurs peuvent utiliser de très anciennes versions de Django (inférieures à 1.4).
Pouvez-vous donner un exemple?

@thedrow juste pour noter, nous devrions activer UTC par défaut en octobre, lorsque le support de Django 1.4 LTS sera terminé (https://www.djangoproject.com/download/)

Oui, nous devrions probablement le faire pour la version 3.2.0.

Maintenant que j'ai vérifié la documentation, j'ai vu que CELERY_ENABLE_UTC est activé par défaut, donc je pense que ce bogue est uniquement lié à la journalisation.

Clôture, car nous n'avons pas les ressources pour mener à bien cette tâche.

Peut être corrigé dans master, voyons s'il revient après la version 4.0.

Comme note utile pour tous ceux qui pourraient trébucher sur cette discussion, j'ai pu exécuter mes ouvriers céleri sur un fuseau horaire différent (UTC) que le projet Django (EST). J'ai donné au céleri un fichier de paramètres Django différent (c'est-à-dire celery_settings), dans lequel je viens d'importer les paramètres d'origine (à partir de l'importation des paramètres *), puis j'écrase le paramètre TIME_ZONE.

Il semble que ce problème persiste dans Celery 4.0.2.
L'horodatage du journal de sortie standard est affecté par le paramètre TIME_ZONE de Django.

Le numéro 4006 suggère le contraire. @marvelph cela peut être corrigé dans le master actuel.

J'ai eu des problèmes avec CELERY_TIMEZONE = 'Europe / Lisbon' et django TIMEZONE = 'Europe / Lisbon' en utilisant le planificateur de battements. il calculerait à tort la date date du prochain is_due.
Sur la version pip, le calcul était négatif et cela ferait des tâches de déjeuner immédiatement pour toujours, sur le maître actuel, je l'ai fait calculer à 1h + temps de répétition.
la définition des deux paramètres sur «UTC» résout le problème.

Nous avons fusionné # 4173 avec master . Si vous pouvez utiliser la branche master et vérifier si le problème persiste, ce serait génial, merci.

J'ai testé avec master, veuillez voir le dernier commentaire ici https://github.com/celery/celery/issues/4041
Il y a toujours un problème avec le fuseau horaire du céleri sur le dernier master, si j'ai à la fois CELERY_TIMEZONE et TIMEZONE pour 'Europe / Lisbonne', le battement de céleri django planifie la tâche suivante à 1h de plus que l'heure correcte

J'ai défini TIME_ZONE et CELERY_TIMEZONE sur Europe / Moscou dans mon projet, mais Celery beat utilise toujours UTC. J'ai également essayé de changer le paramètre CELERY_ENABLE_UTC mais rien n'a changé. Mon heure système est Europe / Moscou et c'est vraiment frustrant

Même problème ici (CELERY_TIMEZONE = TIME_ZONE = Europe / Rome) avec céleri 4.1 et django 1.11.x

• Mes tâches_périodiques ne fonctionnent pas à l'heure prévue. (Je ne l'ai pas corrigé: /)
• Lorsque je réessaye une tâche de céleri, l'ETA calculée est erronée (moins que maintenant), donc la nouvelle tentative est instantanée. Pour ce problème, j'ai calculé l'ETA en le passant à ma tâche réessayée, comme vous pouvez le voir ici (https://github.com/celery/celery/issues/4221#issuecomment-324204504)

Je suis en cours de travail, si je trouve une meilleure solution, j'écrirai ici

J'ai le même problème que @ madEng84 Django 1.11 et Celery 4.1, les nouvelles tentatives de tâches ne fonctionnent pas avec le compte à rebours, uniquement avec eta.

Ceci est un f absolu * ing blague. Tout le céleri est censé faire une tâche -> exécutez-le à temps. Pourquoi diable ces développeurs perdent-ils tout leur temps à ajouter des fonctionnalités exotiques xyz dont personne ne se moque quand il ne peut même pas faire ce pour quoi il est conçu! Putain de merde!

CELERY_TIMEZONE = 'États-Unis / Est'

Les tâches s'exécutent complètement au mauvais moment sur 4.1, c'était correct sur 3. peu importe

@expresspotato Si vous n'êtes pas satisfait du travail que nous faisons GRATUITEMENT, allez à la fourchette de céleri.
Vous pouvez également nous payer pour résoudre vos problèmes.
Sinon, l'auto-droit n'est pas le bienvenu. Considérez ceci comme votre dernier avertissement avant de vous interdire.

Autant que je sache, ce problème a été résolu dans master il y a quelques mois. J'ai utilisé la branche master épinglée à be55de622381816d087993f1c7f9afcf7f44ab33 au lieu de release pour éviter cela et cela a fonctionné comme prévu.
Donc, c'est une excellente question pourquoi n'est-il toujours pas publié? C'est incompréhensible.

@Jamim Nous avons encore quelques pull

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

définir le fuseau horaire «Asie / Shanghai». Le moteur d'exécution calcule l'heure correcte, mais lorsque la nouvelle tentative est activée, eta ne calcule pas «+» en retard. comme ceci '' 'ETA: [2018-04-19 11: 14: 53.216361 + 08: 06]' '' '.Seule la feuille de calcul n'est pas utilisée.Je vais ajouter le nombre de secondes à l'heure donnée . Il travaille, mais qu'est-ce qui n'est pas parfait? J'espère que ma déclaration est utile.

@auvipy
Il est évident que cela n'aurait pas dû être fermé.

J'utilise celery==4.1.0 et Django==1.11.6 .

Indépendamment de ce que j'ai défini pour CELERY_TIMEZONE et TIMEZONE , Celery beat utilise UTC. Aucune combinaison de True et False pour CELERY_ENABLE_UTC et USE_TZ fait une différence.

Il vaudrait mieux reconnaître qu'il s'agit d'un bogue plutôt que de faire croire aux utilisateurs que cela fonctionne.

essayez 4.2rc2 et signalez s'il vous plaît

Je ne comprends pas ce qui se passe avec les paramètres d'heure dans Celery, mais j'ai corrigé
base.py -> maintenant
Et maintenant, il indique l'heure réelle pour le fuseau horaire sélectionné 'Europe / Londres', voir le journal:

[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

Mais la tâche est toujours afficher l'heure au format UTC brut - 2018-06-22 12: 24: 42.350384

Changement de test:

[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

Il semble donc que maintenant les paramètres du fuseau horaire ont un effet, MAIS les tâches utilisent toujours une heure UTC!

Premièrement, cela devrait probablement être l'instance datetime.now, pas datetime.utcnow (), car pourquoi déciderions-nous d'UTC déjà un UTC?

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

Cela me permet désormais de régler l'heure de Londres partout:

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

Mais encore une tâche reçue dans le passé:

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 possible, veuillez ouvrir un PR avec vos modifications et nous pourrons en discuter là-bas.

Vous pouvez essayer l'argument nowfun dans crontab pour définir un fuseau horaire différent

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

J'ai le même problème que date_done en utilisant toujours UTC lorsque j'ai défini

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

sur v4.3.0 installé par pip et redis, donc le problème est résolu ou non?