-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Celery timezone use default UTC timezone ignoring settings. #4842
Comments
Here is really detailed log with references where we can see TZ was set and now it's London summer time . celery_tz_debug.log But task is still UTC default. |
Ok. I found the issue just right for London timezone and day saving options: So if manually set it to int(-3) we can get the real time of London. I'l try to use different options here to avoid overlapping of time zones. ==================
Result: 'Europe/Kiev' same for 'Europe/London'
But in Celery time: Why so? But when I change celery zone - app.conf.timezone = 'Europe/Kiev'
|
So the problem is probably in: Time which used in utcoffset is the system time, which always show you the time when task was actually executed (based on server time), but the time used to plan task can be different - based on app.conf.timezone = 'Europe/Kiev' In this case we have two different realities:
How to avoid this? It should use ONLY the actual system time everywhere, but only in utcoffset use timezone we set in celery setting. In this case we'll have all times equal to system time, but only task execution time will be set to settings timezone. IMHO |
Looks like I was wrong, this is flower change time of execution, DB and real time of task is still 1 hr in the past from actual London time. |
Next step: Flower Tasks board:
Flower "Advanced task options"
django_celery_results_taskresult
This is total mess with dates in code, no idea how to find all declarations and make them somehow dynamic. |
Please, can anybody say me where do Celery get the time? Flower Tasks page shows me: Recieved - 2018-06-23 12:06:07.285 (this is -1 hr from London) How can it be possible? |
So, the issue still is unclear. I feel really unhappy with this, because it affect even MySQL-Django auto_datetime value, so in my system I can see the task were executed 1 hr before the real time. If anyone want to fix this with me, and can find the place where this wrong time is set - please reply. Thanks, |
Keep collecting here related stuff. This issue is wide enough not for celery itself: |
Also: django_celery_results_taskresult uses this option: This is not correct and it's better to use: from django.utils import timezone Maybe |
I hope this is fixed with newer releases |
I have the same problem that cel_app.conf.timezone = 'Asia/Shanghai'
cel_app.conf.enable_utc = True on v4.3.0 installed by pip and redis, so the problem is fixed or not? |
I'm seeing the same thing when I have one worker on a system where UTC is the timezone and another worker has a different timezone (e.g. PST). From what I can tell, the issue is with |
+1 |
I'm also having this issue, is there any fix/workaround? |
+1 |
2 similar comments
+1 |
+1 |
fixes are welcome with a test. |
+1 |
+1 |
+1 |
workaround themanifold@1d5673d |
Checklist
Celery 4.2.0
celery -A proj report
in the issue.(if you are not able to do this, then at least specify the Celery
version affected).
master
branch of Celery.Steps to reproduce
Use any TZ settings in celery settings or Django
Celery will ignore those settings, and set time equal to London -1 hour (just like winter time)
Expected behavior
Celery should use TZ as it was set in settings.
Actual behavior
Celery use UTC default instead.
Related:
#2649
#4006
Steps to possible fix:
Firstly, this probably should be the datetime.now instance, not datetime.utcnow(), because why would we decide to UTC already an UTC?
But still task recieved in older time:
I'm still struggling with actual task time, which is use UTC time, but inspecting task obj content doesn't show me anything:
So, the questions is -
Where do Celery's task take this time?
The text was updated successfully, but these errors were encountered: