Getting RuntimeWarning with django-celery-beat==2.6.0, django==5.0.3

[stefanofusai]

Summary:

I'm getting a weird warning on my celery beat instance: [2024-03-07 22:01:57,546: WARNING/MainProcess] /usr/local/lib/python3.11/site-packages/django/db/models/fields/__init__.py:1595: RuntimeWarning: DateTimeField PeriodicTask.last_run_at received a naive datetime (2024-03-07 22:00:00.253475) while time zone support is active.

• Celery Version: 5.3.6
• Celery-Beat Version: 2.6.0
• Django Version: 5.0.3 (I'm pretty sure that this was happening with Django 4.x as well)

My relevant settings in settings.py

CELERY_BEAT_SCHEDULER = "django_celery_beat.schedulers:DatabaseScheduler"
CELERY_BEAT_SCHEDULE = {
    "my_task": {
        "task": "project.tasks.my_task",
        "schedule": crontab(minute=0),
    },
}
USE_TZ = True

celery.py

app = Celery("tasks",)
app.config_from_object("django.conf:settings", namespace="CELERY")
app.autodiscover_tasks()

Any idea why this is happening? Thank you

[koleror]

Hey! I've been hunting this issue for a while now and never found a fix. Have you found any by any chance? All I can say is it's not django 5 related, as I have the same error using django 4 and 5

[stefanofusai]

Hey! I've been hunting this issue for a while now and never found a fix. Have you found any by any chance? All I can say is it's not django 5 related, as I have the same error using django 4 and 5

Hey @koleror, unfortunately I haven't found any fixes. Luckily it's not a breaking bug but just a warning 😄

Thank you for pointing out that it's not Django 5 related. I said that because I noticed this happening after migrating to Django 5, but it's also possible that I changed some settings when migrating and that's what caused the issue. I will try to have a better look when I have time!

[cclauss]

ruff check --select=DTZ lint rules will encourage using timezone-aware dates and datetimes.

• https://docs.python.org/3/whatsnew/3.12.html#deprecated Scroll to datetime...
• https://docs.djangoproject.com/en/5.0/releases/5.0/#features-removed-in-5-0
• https://docs.astral.sh/ruff/rules/#flake8-datetimez-dtz

% ruff rule DTZ001

call-datetime-without-tzinfo (DTZ001)

Derived from the flake8-datetimez linter.

What it does

Checks for datetime instantiations that do not specify a timezone.

Why is this bad?

datetime objects are "naive" by default, in that they do not include timezone information. "Naive" objects are easy to understand, but ignore some aspects of reality, which can lead to subtle bugs. Timezone-aware datetime objects are preferred, as they represent a specific moment in time, unlike "naive" objects.

By providing a non-None value for tzinfo, a datetime can be made timezone-aware.

Example

import datetime

datetime.datetime(2000, 1, 1, 0, 0, 0)

Use instead:

import datetime

datetime.datetime(2000, 1, 1, 0, 0, 0, tzinfo=datetime.timezone.utc)

Or, on Python 3.11 and later:

import datetime

datetime.datetime(2000, 1, 1, 0, 0, 0, tzinfo=datetime.UTC)

[stefanofusai]

@cclauss Thank you for your feedback, I already have that rule enabled. The field that is being generated without a timezone is internal to django-celery-beat, it is PeriodicTask.last_run_at as you can see from the warning log so I'm not sure what I'm doing wrong/what I'm supposed to do.

[cclauss]

Understood. There are lots of PRs and issues on last_run_at...

• https://github.com/search?q=repo%3Acelery%2Fdjango-celery-beat+last_run_at&type=pullrequests

[cclauss]

Would it be possible to add a test that fails so we can all see the failure and we can prove any proposed fixes?

• https://github.com/celery/django-celery-beat/tree/main/t/unit

[stefanofusai]

Unfortunately I'm unable to reproduce this issue to further debug it, the warning logs are emitted randomly when running celery locally but are emitted at every task execution when in production inside a docker container.