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
task_tz_debug.log

But task is still UTC default.

Ok. I found the issue just right for London timezone and day saving options:
The problem is here in time -> utcoffset
It tries to get the real timezone for UTC with day saving, but delta is too different for actual time.
return -3

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.

==================

import time as _time
if tm_isdst_v:
    time_altzone = _time.altzone // 3600
    debug("time_altzone day savetime delta: %s", time_altzone)
time_timezone = _time.timezone // 3600
debug("time_timezone not day savetime delta: %s", time_timezone)

Result: 'Europe/Kiev' same for 'Europe/London'

611 MainThread  2018-06-22 18:55:16,406 DEBUG   date_times          <module>              L:43    time_altzone day savetime delta: -3
611 MainThread  2018-06-22 18:55:16,406 DEBUG   date_times          <module>              L:45    time_timezone not day savetime delta: -2

But in Celery time:
[2018-06-22 17:07:06,550: INFO/MainProcess] time_altzone day savetime delta: -1
[2018-06-22 17:07:06,551: INFO/MainProcess] time_timezone not day savetime delta: 0

Why so?
Hm yes, this is usual diff for UTC of London and UTC+2 of Kyiv

But when I change celery zone - app.conf.timezone = 'Europe/Kiev'
It still uses:

time_altzone day savetime delta: -1
time_timezone not day savetime delta: 0

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:

• the time we want to use in Celery as time when to schedule tasks (when server in London, but we want to execute based on Kyiv for example)
• the time we actually have in our system, which used to understand when task were fired on system - which is different from point 1

How to avoid this?
I don't know, from my perspective I have only bug with daily time saving settings, where system time is 16:00, Kyiv time is 18:00, but Celery (when use all TZ settings) time is 15:00!!!

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:
Hardcode time.py ->
@cached_property def utc(self): get_tz = pytz_timezone('Europe/London')

Flower Tasks board:

2018-06-22 19:53:51.785 | 2018-06-22 19:53:51.789
-- | --

Flower "Advanced task options"

Received | 2018-06-22 20:53:51.785712 BST
-- | --
Sent | 2018-06-22 20:53:51.781479 BST
Started | 2018-06-22 20:53:51.789844 BST
Succeeded | 2018-06-22 20:53:52.139911 BST

django_celery_results_taskresult

2018-06-22 19:53:52.124279

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?
This is just unbelievable, I totally changed the Celery time representation, it now use London time in Beat and logging everything in right timezone, BUT!!!

Flower Tasks page shows me: Recieved - 2018-06-23 12:06:07.285 (this is -1 hr from London)
Flower TasK page, for one separate task shows me: All time according to 2018-06-23 13:06:07.285740 BST (This is the right London time!)
AND MySQL table django_celery_results_taskresult shows me - 2018-06-23 12:06:07.091785

How can it be possible?
Where else Celery can get time? Or this is also a bug in Flower and Django Celery module?

So, the issue still is unclear.
The code itself tries to do a proper work and set time zone depend on difference between UTC and TZ user set in celery setting, but it sometimes get wrong time from "raw" UTC without any corrections, and this is why task record in Flower and MySQL had a wrong time - not the real server or TZ time.

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.
In other words - I spent about 4 days to understand this mechanism in Celery and see some kind of bugs, but I have no much free time to support this by my own.

Thanks,

Keep collecting here related stuff. This issue is wide enough not for celery itself:
celery/django-celery#222

Also: django_celery_results_taskresult uses this option:
date_done = models.DateTimeField(_('done at'), auto_now=True
This is why task were saved with UTC.

This is not correct and it's better to use:

from django.utils import timezone
date_done = models.DateTimeField(_('done at'), default=timezone.now)

Maybe

I hope this is fixed with newer releases

I have the same problem that date_done always using UTC when I have set

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 event_from_message attempting to localize a timestamp that is in UTC already. It's ignoring all settings and blindly calling adjust_timestamp, which is a no-op as long as all workers are in the same timezone, but incorrectly "localizes" the timestamp if there is an offset. event_from_message takes an optional localize parameter that defaults to True. Since the parameter doesn't seem to be passed from the caller, it's always attempting to localize a value that should remain in UTC.

+1

I'm also having this issue, is there any fix/workaround?

+1

fixes are welcome with a test.

+1

+1

+1

workaround themanifold@1d5673d