Celery: CELERY_TIMEZONE und CELERY_ENABLE_UTC haben keine Auswirkung

Die Anweisungen CELERY_TIMEZONE und CELERY_ENABLE_UTC werden für Sellerie-Beat und nicht für Worker ausgeführt.

Die Anmeldung bei Sellerie berücksichtigt nicht CELERY_ENABLE_UTC, sondern nur einen einfachen Wrapper für das Python-Protokollierungsmodul.

CELERY_ENABLE_UTC ist standardmäßig nicht aktiviert, da möglicherweise sehr alte Django-Versionen (unter 1.4) verwendet werden.
Können Sie bitte ein Beispiel nennen?

@thedrow Nur um zu beachten, wir sollten UTC standardmäßig im Oktober aktivieren, wenn die Unterstützung für Django 1.4 LTS beendet wird (https://www.djangoproject.com/download/).

Ja, wir sollten es wahrscheinlich für 3.2.0 tun.

Nachdem ich die Dokumentation überprüft habe, habe ich festgestellt, dass CELERY_ENABLE_UTC standardmäßig aktiviert ist. Ich denke, dieser Fehler hängt nur mit der Protokollierung zusammen.

Schließen Sie dies, da wir nicht über die Ressourcen verfügen, um diese Aufgabe abzuschließen.

Kann im Master behoben sein, mal sehen, ob es nach der Version 4.0 wieder kommt.

Als hilfreiche Anmerkung für alle, die über diese Diskussion stolpern könnten, konnte ich meine Sellerie-Arbeiter in einer anderen Zeitzone (UTC) als das Django-Projekt (EST) betreiben. Ich habe Sellerie eine andere Django-Einstellungsdatei (dh Sellerie-Einstellungen) gegeben, in die ich nur die ursprünglichen Einstellungen (aus dem Einstellungsimport *) importiere und dann den Parameter TIME_ZONE überschreibe.

Es scheint, dass dieses Problem in Sellerie 4.0.2 weiterhin besteht.
Der Zeitstempel des Standardausgabeprotokolls wird durch den Parameter TIME_ZONE von Django beeinflusst.

Ausgabe Nr. 4006 schlägt das Gegenteil vor. @marvelph Dies kann im aktuellen Master behoben sein.

Ich hatte Probleme mit CELERY_TIMEZONE = 'Europe / Lisbon' und django TIMEZONE = 'Europe / Lisbon' mit dem Beat Scheduler. Es würde das Datum des nächsten is_due falsch berechnen.
Bei der Pip-Version war die Berechnung negativ, und das würde die Aufgaben für immer sofort zu Mittag essen. Bei der aktuellen Master-Version ließ ich sie auf 1 Stunde + Wiederholungszeit berechnen.
Wenn Sie beide Einstellungen auf 'UTC' setzen, wird das Problem behoben.

Wir haben # 4173 zu master . Wenn Sie den Zweig master und prüfen können, ob das Problem weiterhin besteht, wäre es großartig, danke.

Ich habe mit Master getestet. Den neuesten Kommentar finden Sie hier https://github.com/celery/celery/issues/4041
Es gibt immer noch ein Problem mit der Sellerie-Zeitzone auf dem neuesten Master. Wenn ich sowohl CELERY_TIMEZONE als auch TIMEZONE für 'Europe / Lisbon' habe, plant der Django-Sellerie-Beat die nächste Aufgabe auf 1 Stunde mehr als die richtige Zeit

Ich habe sowohl TIME_ZONE als auch CELERY_TIMEZONE in meinem Projekt auf Europa / Moskau eingestellt, aber Celery Beat verwendet immer noch UTC. Ich habe auch versucht, die Einstellung CELERY_ENABLE_UTC zu ändern, aber nichts hat sich geändert. Meine Systemzeit ist Europa / Moskau und das ist wirklich frustrierend

Gleiches Problem hier (CELERY_TIMEZONE = TIME_ZONE = Europa / Rom) mit Sellerie 4.1 und Django 1.11.x.

• Meine periodic_tasks funktionieren nicht zur erwarteten Zeit. (Ich habe es nicht behoben: /)
• Wenn ich eine Sellerie-Aufgabe erneut versuche, ist die berechnete ETA falsch (geringer als jetzt), sodass die Wiederholung sofort erfolgt. Für dieses Problem habe ich die Eta berechnet, die an meine wiederholte Aufgabe übergeben wird, wie Sie hier sehen können (https://github.com/celery/celery/issues/4221#issuecomment-324204504)

Ich bin in Arbeit, wenn ich eine bessere Lösung finde, werde ich hier schreiben

Ich habe das gleiche Problem wie @ madEng84 Django 1.11 und Celery 4.1. Die Wiederholung von Aufgaben funktioniert nicht mit Countdown, sondern nur mit eta.

Dies ist ein absolutes f * Witz ing. Alles, was Sellerie tun soll, ist Aufgabe -> pünktlich ausführen. Warum zum Teufel verschwenden diese Entwickler ihre ganze Zeit damit, exotische Funktionen xyz hinzuzufügen, über die sich niemand Gedanken macht, wenn sie nicht einmal das tun können, wofür sie entwickelt wurden? Heiliger Strohsack!

CELERY_TIMEZONE = 'US / Eastern'

Aufgaben laufen auf 4.1 zur völlig falschen Zeit, waren auf 3. was auch immer in Ordnung

@expresspotato Wenn Sie mit der Arbeit, die wir geben Sie Sellerie.
Sie können uns auch bezahlen, um Ihre Probleme zu beheben.
Andernfalls ist eine Selbstberechtigung nicht erwünscht. Betrachten Sie dies als Ihre letzte Warnung, bevor ich Sie verbiete.

Soweit ich weiß, wurde dieses Problem vor einigen Monaten im Master behoben. Ich habe master branch verwendet, der an be55de622381816d087993f1c7f9afcf7f44ab33 angeheftet ist, anstatt dies freizugeben, um dies zu vermeiden, und es hat wie erwartet funktioniert.
Es ist also eine gute Frage, warum es immer noch nicht veröffentlicht wird. Es ist unverständlich.

@Jamim Wir müssen noch einige Pull-Anfragen zusammenführen, bevor wir sie veröffentlichen. Sehen Sie den Meilenstein.

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

Stellen Sie die Zeitzone 'Asia / Shanghai' ein. Die Laufzeit berechnet die korrekte Zeit, aber wenn der Wiederholungsversuch aktiviert ist, berechnen Sie nicht '+' hinter der Zeit. so '' 'ETA: [2018-04-19 11: 14: 53.216361 + 08: 06]' ''. Nur das Berechnungsblatt wird nicht verwendet. Ich werde die Anzahl der Sekunden zur angegebenen Zeit hinzufügen . Er arbeitet, aber was ist nicht perfekt? Ich hoffe, meine Aussage ist nützlich.

@auvipy
Es ist offensichtlich, dass dies nicht geschlossen werden sollte.

Ich verwende celery==4.1.0 und Django==1.11.6 .

Unabhängig davon, was ich für CELERY_TIMEZONE und TIMEZONE , verwendet Celery Beat UTC. Keine Kombination von True und False für CELERY_ENABLE_UTC und USE_TZ macht einen Unterschied.

Es wäre besser, dies als Fehler anzuerkennen, als die Benutzer glauben zu lassen, dass es funktioniert.

versuche 4.2rc2 und melde dich bitte

Ich kann nicht verstehen, was mit den Zeiteinstellungen in Sellerie los ist, aber ich habe es behoben
base.py -> jetzt
Und jetzt wird die tatsächliche Zeit für die ausgewählte Zeitzone 'Europa / London' angezeigt, siehe Protokoll:

[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

Aber Aufgabe ist immer noch Zeit als rohe UTC anzuzeigen - 2018-06-22 12: 24: 42.350384

Teständerung:

[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

Es scheint also, als ob jetzt die Zeitzone der Einstellungen wirksam wird, ABER Aufgaben verwenden immer noch eine UTC-Zeit!

Erstens sollte dies wahrscheinlich die Instanz datetime.now sein, nicht datetime.utcnow (), denn warum sollten wir uns für UTC bereits als UTC entscheiden?

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

Jetzt kann ich überall in London die Zeit einstellen:

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

Aber noch Aufgabe in älterer Zeit erhalten:

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 wenn möglich, bitte öffnen Sie eine PR mit Ihren Änderungen und wir können es dort diskutieren.

Sie können das Argument nowfun in crontab ausprobieren, um eine andere Zeitzone festzulegen

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

Ich habe das gleiche Problem, dass date_done immer UTC verwendet, wenn ich eingestellt habe

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

auf v4.3.0 von pip und redis installiert, also ist das problem behoben oder nicht?