Celery: CELERY_TIMEZONE和CELERY_ENABLE_UTC无效

指令CELERY_TIMEZONE和CELERY_ENABLE_UTC适用于芹菜节拍，而不适用于工人。

celery中的日志记录不考虑CELERY_ENABLE_UTC，它只是python日志记录模块的简单包装。

默认情况下未启用CELERY_ENABLE_UTC，因为人们可能会使用非常老的Django版本（低于1.4）。
你能举个例子吗？

@thedrow只是要注意，我们应该在10月默认启用UTC，届时Django 1.4 LTS支持将终止（https://www.djangoproject.com/download/）

是的，对于3.2.0，我们可能应该这样做。

现在，我检查了文档，我看到默认情况下已启用CELERY_ENABLE_UTC，因此我认为此错误仅与日志记录有关。

由于我们没有足够的资源来完成此任务，因此请关闭该窗口。

可能已在master中修复，让我们来看一下4.0版本之后是否又回来了。

作为对可能不熟悉此讨论的任何人的帮助，我能够在与Django项目（EST）不同的时区（UTC）上运行芹菜工人。 我给了celery一个不同的Django设置文件（即celery_settings），在其中我只是导入原始设置（从settings import *），然后覆盖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 celery beat将下一个任务安排为比正确时间多1h

我在我的项目中将TIME_ZONE和CELERY_TIMEZONE都设置为Europe / Moscow，但Celery beat仍使用UTC。 我也尝试过切换CELERY_ENABLE_UTC设置，但未做任何更改。 我的系统时间是在欧洲/莫斯科，这真的很令人沮丧

芹菜4.1和Django 1.11.x的相同问题（CELERY_TIMEZONE = TIME_ZONE =欧洲/罗马）

• 我的periodic_tasks在预期的时间无法正常工作。 （我还没有解决它：/）
• 当我重试芹菜任务时，计算出的ETA是错误的（比现在少），因此重试是瞬时的。 对于这个问题，我已经计算出将它传递给我重试的任务的eta，您可以在这里看到（https://github.com/celery/celery/issues/4221#issuecomment-324204504）

我在进行中，如果我找到更好的解决方案，我会在这里写

我有与@ madEng84 Django 1.11和Celery 4.1相同的问题，任务重试不适用于倒数计时，仅适用于eta。

这是一个绝对F *荷兰国际集团的笑话。 芹菜应该做的只是任务->按时运行。 为什么这些开发人员会浪费所有的时间来添加xyz异国特色的功能，而当它甚至无法完成其设计目的时，没人会对此表示怀疑！ 碉堡了！

CELERY_TIMEZONE ='美国/东部'

任务在4.1上的完全错误的时间运行，在3.上还可以

@expresspotato如果您对工作不满意，我们免费提供叉芹菜。
您也可以向我们付款以解决您的问题。
否则，我们不欢迎您使用自我权利。 在禁止我之前，请考虑一下这是您的最后警告。

据我所知，这个问题是几个月前在大师版中解决的。 我将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。 CELERY_ENABLE_UTC和USE_TZ的True和False组合没有任何区别。

承认这个错误比让用户认为它有效更好。

尝试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（如果可能），请打开您的更改的PR，我们可以在那里进行讨论。

您可以尝试在crontab使用nowfun参数来设置不同的时区

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

在通过pip和redis安装的v4.3.0上，是否已解决问题？