Celery: CELERY_TIMEZONE e CELERY_ENABLE_UTC não surtem efeito

As diretivas CELERY_TIMEZONE e CELERY_ENABLE_UTC são trabalhadas para batida de aipo, não trabalhador.

O registro no aipo não leva em consideração CELERY_ENABLE_UTC, é apenas um empacotador simples para o módulo de registro em python.

CELERY_ENABLE_UTC não é habilitado por padrão porque as pessoas podem usar versões muito antigas do Django (abaixo de 1.4).
Você pode dar um exemplo?

@thedrow apenas para observar, devemos habilitar o UTC por padrão em outubro, quando o suporte do Django 1.4 LTS será encerrado (https://www.djangoproject.com/download/)

Sim, provavelmente devemos fazer isso para 3.2.0.

Agora que verifiquei a documentação, vi que CELERY_ENABLE_UTC está habilitado por padrão, então acho que esse bug está relacionado apenas ao registro.

Fechando isso, pois não temos os recursos para concluir esta tarefa.

Pode ser corrigido no master, vamos ver se volta após o lançamento 4.0.

Como uma observação útil para qualquer um que possa tropeçar nesta discussão, fui capaz de executar minhas operadoras de aipo em um fuso horário (UTC) diferente do projeto Django (EST). Eu dei ao celery um arquivo de configurações diferente do Django (ou seja, celery_settings), no qual eu apenas importo as configurações originais (da importação de configurações *) e sobrescrevo o parâmetro TIME_ZONE.

Parece que esse problema ainda permanece no Celery 4.0.2.
O registro de data e hora do log de saída padrão é afetado pelo parâmetro TIME_ZONE do Django.

A edição # 4006 sugere o oposto. @marvelph isso pode ser corrigido no mestre atual.

Tive problemas com CELERY_TIMEZONE = 'Europe / Lisbon' e django TIMEZONE = 'Europe / Lisbon' usando o programador de batida. ele calcularia erroneamente as datas do próximo is_due.
Na versão pip eu tinha o cálculo negativo e que iria almoçar tarefas imediatamente para sempre, no master atual fiz calcular para 1h + tempo de repetição.
definir ambas as configurações para 'UTC' corrige o problema.

Nós fundimos # 4173 com master . Se você puder usar o branch master e verificar se o problema persiste, seria ótimo, obrigado.

Eu testei com o mestre, por favor, veja o comentário mais recente aqui https://github.com/celery/celery/issues/4041
Ainda há um problema com o fuso horário do aipo no último mestre, se eu tiver CELERY_TIMEZONE e TIMEZONE para 'Europa / Lisboa', a batida do aipo django programa a próxima tarefa para 1h a mais do que o tempo correto

Tenho TIME_ZONE e CELERY_TIMEZONE configurados para Europa / Moscou em meu projeto, mas o Celery beat ainda usa UTC. Também tentei mudar a configuração CELERY_ENABLE_UTC, mas nada mudou. A hora do meu sistema é Europa / Moscou e isso é realmente frustrante

O mesmo problema aqui (CELERY_TIMEZONE = TIME_ZONE = Europe / Rome) com aipo 4.1 e django 1.11.x

• Minhas periodic_tasks não estão funcionando no horário esperado. (Eu não consertei: /)
• Quando tento novamente uma tarefa de aipo, o ETA calculado está errado (menor do que agora), então a nova tentativa é instantânea. Para este problema, calculei o eta passando para minha tarefa repetida, como você pode ver aqui (https://github.com/celery/celery/issues/4221#issuecomment-324204504)

Estou em Work in Progress, se eu encontrar uma solução melhor, escreverei aqui

Eu tenho o mesmo problema que @ madEng84 Django 1.11 e Celery 4.1, a repetição de tarefas não funciona com contagem regressiva, apenas com eta.

Este é um f absoluta * ing brincadeira. Tudo o que o aipo deve fazer é tarefa -> executá-lo na hora certa. Por que diabos esses desenvolvedores perdem todo o seu tempo adicionando recursos exóticos xyz que ninguém dá a mínima quando ele nem consegue fazer o que foi projetado para fazer! Puta merda!

CELERY_TIMEZONE = 'EUA / Leste'

As tarefas são executadas na hora completamente errada no 4.1, estava tudo bem de volta no 3. tanto quanto

@expresspotato Se você não está feliz com o trabalho que fazemos GRATUITAMENTE,
Você também pode nos pagar para resolver seus problemas.
Caso contrário, o direito próprio não é bem-vindo. Considere este seu último aviso antes de eu bani-lo.

Pelo que eu sei, esse problema foi corrigido no master há alguns meses. Usei master branch fixado em be55de622381816d087993f1c7f9afcf7f44ab33 em vez de release para evitar isso e funcionou conforme o esperado.
Então, é uma ótima pergunta por que ainda não foi lançado? Isso é incompreensível.

@Jamim Temos mais algumas solicitações pull para mesclar antes de liberar. Veja o marco.

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

defina o fuso horário 'Ásia / Xangai'. O tempo de execução calcula o tempo correto, mas quando a nova tentativa está habilitada, eta não calcula o tempo '+' em atraso. assim '' 'ETA: [2018-04-19 11: 14: 53.216361 + 08: 06]' '' '. Apenas a folha de cálculo não é usada. Vou adicionar o número de segundos ao tempo fornecido . Ele funciona, mas o que não é perfeito? Espero que minha declaração seja útil.

@auvipy
É óbvio que isso não deveria ter sido fechado.

Estou executando celery==4.1.0 e Django==1.11.6 .

Independentemente do que eu defini para CELERY_TIMEZONE e TIMEZONE , a batida de aipo usa UTC. Nenhuma combinação de True e False para CELERY_ENABLE_UTC e USE_TZ faz diferença.

Seria melhor reconhecer que este é um bug do que fazer os usuários pensarem que funciona.

tente 4.2rc2 e relate por favor

Não consigo entender o que está acontecendo com as configurações de tempo no aipo, mas eu consertei
base.py -> agora
E agora ele informa o tempo real para o fuso horário selecionado 'Europa / Londres', consulte o log:

[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

Mas a tarefa ainda é a hora do show como UTC - 22/06/2018 12: 24: 42.350384

Mudança de teste:

[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

Portanto, parece que agora as configurações de fuso horário têm efeito, MAS as tarefas ainda estão usando um horário UTC!

Em primeiro lugar, provavelmente deve ser a instância datetime.now, não datetime.utcnow (), porque por que decidiríamos UTC já ser UTC?

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

Agora, posso definir a hora de Londres em qualquer lugar:

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

Mas ainda tarefa recebida em tempos mais antigos:

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 se possível, abra um PR com suas alterações e podemos discuti-lo lá.

Você pode tentar o argumento nowfun em crontab para definir um fuso horário diferente

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

Eu tenho o mesmo problema que date_done sempre usando UTC quando eu configurei

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

na v4.3.0 instalada por pip e redis, então o problema foi corrigido ou não?