croniter-mojo

A drop-in faster replacement for the croniter package's get_next / get_prev on 5-field cron expressions, powered by a clean-room Mojo kernel — with a pure-Python engine for platforms without a native build (including Windows — tested there in CI: windows-fallback). Zero runtime dependencies.

from datetime import datetime
from zoneinfo import ZoneInfo
from croniter_mojo import get_next, get_prev  # same results as croniter

get_next("0 9 * * mon-fri", datetime(2026, 9, 19, 14, 30))
# datetime(2026, 9, 21, 9, 0)

get_prev("30 2 * * *", datetime(2026, 3, 10, 12, 0, tzinfo=ZoneInfo("America/New_York")))
# datetime(2026, 3, 10, 2, 30, tzinfo=ZoneInfo("America/New_York"))  (DST-aware)

• Same results: returned datetimes are identical to the published croniter package (6.2.4) for the supported scope — the differential suite compares thousands of cases element-for-element on both the native and fallback backends, including expand_from_start_time (a no-op in croniter 6.2.4) and zoneinfo DST boundaries (spring-forward gaps, fall-back folds, sub-hour Lord Howe shifts).
• Supported scope: *, */n, a-b (wrapping allowed), lists, steps a/n and a-b/n, names (jan/mon, case-insensitive), ? in the day-of-month/day-of-week fields, l (last day of month) in dom lists, nth-weekday hash specs (5#3), dom/dow OR-vs-AND (day_or=True/False), start_date truncation semantics, and naive or zoneinfo-aware datetimes. Not supported: 6/7-field expressions (seconds/year fields) and ret_type=float — this package always returns datetimes.
• Much faster iteration: native bitmask seek instead of Python-level datetime arithmetic for every candidate minute — see the benchmark below.
• No toolchain needed: per-platform wheels ship the compiled kernel. Everywhere else the package transparently uses its pure-Python engine, which returns identical results.
• Force the fallback with CRONITER_MOJO_DISABLE_NATIVE=1; inspect the active backend with croniter_mojo.backend_info().

Benchmark

Measured on this machine (Apple M4 Max, macOS arm64, Python 3.12, Mojo 1.1.0, croniter 6.2.4), median of 5 runs. "Cold" = first call for an expression (parse + seek, no cache); "warm" = steady-state per-call cost with the parsed schedule cached. Chains = 1000 successive get_next calls (scheduler roll-out workload). Correctness is asserted before any timing.

The pure-Python fallback returns identical results; the native kernel is the speedup above. Full method: benchmarks/bench_croniter.py in the repository.

Source, benchmarks, and development: https://github.com/thyn-ai/mojo-kernels

License: Apache-2.0, © 2026 Algenta