Re. Issue #874: guarantee tz aware current datetime for timezone.localtime

[djarv]

re. Issue #874, draft PR as per request.

timezone.localtime requires a timezone aware datetime, and now will return a naive datetime if setting USE_TZ is False, resulting in failed startup ValueError: localtime() cannot be applied to a naive datetime.

USE_TZ and DJANGO_CELERY_BEAT_TZ_AWARE settings should not be relevant to the output of method DatabaseScheduler.get_excluded_hours_for_crontab_tasks, which is a list of naive hour strings.

Maybe there is a more conforming way of accomplishing this than my suggestion, but cannot use maybe_make_aware(now()) because now() returns naive local time, and maybe_make_aware requires naive utc time (e.g. from depricated datetime.utcnow()).

While I've had this running on my UTC timezone dev server for a few days, this is not tested, particularly for other timezones, and I do not claim to fully understand how the timezone/naive timestamp management works through these modules.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.08%. Comparing base (cf04a7b) to head (b79fff0).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #877   +/-   ##
=======================================
  Coverage   88.08%   88.08%           
=======================================
  Files          32       32           
  Lines         965      965           
  Branches      100      100           
=======================================
  Hits          850      850           
  Misses         98       98           
  Partials       17       17           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull Request Overview

This PR addresses Issue #874 by ensuring that the datetime passed to timezone.localtime() is timezone aware.

• Replaced timezone.localtime(now()) with timezone.localtime(datetime.datetime.now(datetime.timezone.utc)) to avoid ValueError when USE_TZ is False.
• Added inline commentary specifying that timezone.localtime() expects an aware datetime.

Comments suppressed due to low confidence (1)

django_celery_beat/schedulers.py:406

• Ensure that the datetime module is imported (e.g., 'import datetime') so that datetime.datetime.now(datetime.timezone.utc) works as expected.

current_time = timezone.localtime(

[auvipy]

would you mind investigate more places where this type of changes are needed?

[djarv]

Code refactor in #879 has removed the affected code that this PR was looking to address. Re-based my fork which closed this draft PR.