ValueError: localtime() cannot be applied to a naive datetime

[xiaobao0505]

There is an error when starting the project：
django-celery-beat: 2.8.0

1.celery -A app beat -l info
2.

[xiaobao0505]

It should be a bug triggered when USE_TZ is set to False.

[cristianfavaro]

Having the same issue.
I've been using it as "USE_TZ = False" in Django settings and was ok. But now it is not working. Crazy.

==EDIT
It is something with the 2.8.0 version.
I downgraded mine to 2.7.0 and works fine with USE_TZ=False

[auvipy]

can you guys help to track the commit causing this issue? any test to reproduce it?

[djarv]

Commit fc64741, django_celery_beat/schedulers.py, line 404 in the new get_excluded_hours_for_crontab_tasks() function.

timezone.localtime expects a tz aware timestamp, and .utils.now() will return naive timestamp if USE_TZ is False.
I have a local copy in dev replacing now() with datetime.datetime.now(datetime.timezone.utc), which as I understand timezone.localtime can use to convert to whatever local time it is trying to do - not hitting TZ unaware database with this date. I'm not sure if there is a more official django/celerybeat way of doing what I've changed but it seems to be running again. This needs testing properly though and my server is UTC so I'm not in a position to test timezones.

Recreate: django setting USE_TZ is False (when running a TZ unaware db).
DJANGO_CELERY_BEAT_TZ_AWARE setting also exists but won't cause this bug, though I assume things will fall apart if USE_TZ and DJANGO_CELERY_BEAT_TZ_AWARE aren't set the same?

[auvipy]

Would you mind a draft pr with possible fix?

[djarv]

draft PR #877 created with the change I mentioned.

[LT-lt12]

It should be a bug triggered when USE_TZ is set to False.

确实存在此问题，你尝试解决了吗？我试图尝试

但这样的话，在有两个相同start_time任务时，会让celery_beat无限循环

[pulse-mind]

Same as @cristianfavaro

[auvipy]

thanks. we have this open draft pr, can any of you try and verify it? #877

[LT-lt12]

thanks. we have this open draft pr, can any of you try and verify it? #877

This PR cannot solve this problem. I am in +8:00.

Below is my configuration and version information.
TIME_ZONE = 'Asia/Shanghai'
USE_TZ = False
CELERY_TIMEZONE = TIME_ZONE
DJANGO_CELERY_BEAT_TZ_AWARE = False

django==3.2.0
django-celery-beat==2.8.0
pytz==2019.3
celery==5.3.0
cron-descriptor==1.4.5

[djarv]

This PR cannot solve this problem. I am in +8:00.

The utc-timestamp is simply to create a tz aware datetime which is then converted to the set timezone by timezone.localtime(), though if it didn't do that when you tested it please let me know the outcome you got.

However...
Merged PR #879 removes and refactors the affected code that causes this issue. Hence draft PR #877 now closed.

[auvipy]

thanks. we now got a new release