We Rewrote a Cron Library in Rust and Almost Missed the Deadline Doing It

Srimoneyshankar Ajith — Sat, 08 Aug 2026 11:46:10 +0000

Ten hours, one 46 nanosecond bug, and a mild existential crisis about my degree.

How it all started

Some months ago I read about Anthropic rewriting Bun in Rust, and the part that stuck was not the speed. It was that they had to prove the new thing behaved like the old thing on a codebase nobody could afford to break. That is a much harder problem than writing fast code.

So when a hackathon turned up whose whole premise was "take a library, rewrite it in another language, prove you did not change its behaviour," I signed up immediately. Then did nothing for weeks. Then opened an empty folder on the final morning with about ten hours left.

We submitted with roughly five minutes to spare. This was not a plan.

What we picked

We rewrote croniter, a Python library that answers one question: given a schedule like "every 30 minutes between 1am and 3am" and a moment in time, when does it next run, and when did it last run.

Sounds like an afternoon. It is not, because time is a nightmare. Twice a year the clocks change. In spring an hour vanishes, so a job set for 2:30am has no 2:30am to run at. In autumn 1:30am happens twice, so the same job could run zero times, once, or twice depending on who wrote the library and what mood they were in. On top of that, cron syntax carries fifteen years of accumulated weirdness. A character for "last day of the month." Another for "nearest weekday." A rule about days and weekdays that looks broken and is deliberate, because it has behaved that way since the seventies and a lot of servers quietly depend on it.

Get any of that subtly wrong and nothing crashes. No stack trace, no alert. Your job just runs at the wrong time, once, in November, and six weeks later someone says the numbers look a bit off and nobody ever connects the two.

The real reason we picked it, though: this library ships with nearly three times as much test code as library code. That mattered more than anything else.

The part where I questioned my degree

My harness was Claude Code. I went in wanting to see how far it could actually be pushed, and I set it up properly first: a decent pile of skills and custom instructions to shape the output rather than just typing at it and hoping.

The first few hours were a rude awakening, in both directions.

Direction one, which I did not enjoy. It is genuinely unsettling to watch a machine produce, in twenty minutes, work that I would have spent a week on. I am a junior in college. I am currently paying money and time to learn things that were appearing on my screen faster than I could read them. There is a specific feeling that comes with that, and it is not excitement. It is closer to "what exactly am I doing here." I spent a real part of that morning half seriously wondering whether I should be aiming at a different role entirely.

Direction two, which arrived a few hours later and fixed the first one.

The output only looked effortless from a distance. Up close it needed constant steering. The model does not remember what it decided forty minutes ago, so it would contradict itself across two files while sounding completely confident in both. It would solve the problem I described rather than the problem I had. It would produce something that compiled, passed, and was quietly the wrong shape. Every one of those was caught because somebody in the room had enough of an idea of what correct looked like to notice.

That is the actual skill now. Not typing the code. Knowing enough to tell when the answer is wrong, and knowing what to build so that being wrong becomes visible.

Which is what turned the day around. Instead of reading generated code line by line, we spent the early hours wiring up the original library's own test suite to run directly against our Rust version. After that, every change came back as one number: 248 tests, how many pass. No judgement calls, no reading a diff and deciding it looked fine. A number that went up or did not.

Once that loop existed the whole thing changed character. Ask, run, read the failure, feed it back. It stopped feeling like an argument and started feeling like a build. The rest of the day was smooth in a way the first three hours absolutely were not.

The other habit worth stealing: write decisions down the moment you make them. Every time we deliberately did something differently from the original, it went into a file with the reasoning, immediately. That file ended up with 19 entries. It meant that at hour eight, when someone asked why the timezone handling had been pulled out of the search loop, the answer already existed instead of being reconstructed by two tired people and a model with no memory.

So, no, I am not pivoting. The models keep improving and compute keeps getting cheaper, and I genuinely do not know where that lands in three years. But the useful position right now is being the person who can tell good output from confident nonsense, and that still requires knowing the material. That is what I am aiming at.

Proving it, without cheating

The obvious way to prove a rewrite matches the original is to run them side by side. The rules did not allow that, rightly, because the easy version means quietly embedding Python inside your Rust program and calling it a port.

So we did four other things.

Recorded everything. We ran the original test suite once with a recorder attached, capturing every question it asked the library and every answer it got back. About 15,800 exchanges. Our Rust version replays all of them and checks the answers match, with no Python present at replay time.

Let the original tests drive our code. We wrote a small adapter so that when the Python suite says import croniter, it gets a thin wrapper that forwards each call to our Rust program and hands the reply back. The tests never know anything changed. Python calling out to a separate program is the direction where you are clearly not smuggling an interpreter in the back door.

Threw random garbage at both. A script that generates random schedules and start times, runs them through Python and through us, and shouts if the answers differ. This found the two most interesting problems we hit, neither of which it was built to look for.

Wrote tests that ignore Python entirely. Everything above checks that we agree with Python, and none of it catches a mistake we both make. So we also tested things that must be true of any correct scheduler: moving forward always moves forward, forward then backward never overshoots, stepping forward never skips a valid time (checked by probing every minute in between), and a long run of steps never gets stuck, since a scheduler that stalls will hang your service and is invisible to a test that takes one step.

Those last ones found nothing. I still think they are the best tests in the repo, because they are the only ones that could have.


Original Python suite, unedited, run against our Rust version	248 of 248
Recorded exchanges replayed and matched	15,827 of 15,827
Random comparison cases with no disagreement	14,610
Speed, depending on the task	8x to 185x faster

Thirteen recorded exchanges are excluded and listed by name. Ten use a feature that deliberately picks random values, so there is no fixed answer to check. Three are calls Rust will not let you write at all. Naming your exclusions costs a rounder number and buys the right to be believed.

The 46 nanosecond bug, and the worse bug behind it

At some point we noticed our version occasionally reporting that the last run happened a whole day earlier than it actually did. Not a few seconds. A day.

Python's clock stores time down to the microsecond. The Rust library we used goes finer, to the nanosecond. When the search stepped backwards by one microsecond to look just before the current moment, Python landed exactly on the second and we landed 46 nanoseconds underneath it. Clearing the seconds field then rounded that into the previous minute, and the search went hunting in the wrong day entirely.

You cannot find that by reading the code. Both versions look right, and in a narrow sense both are, since each does exactly what its own clock library promises. We only caught it because we were comparing against the real thing at full precision. The fix rounds our clock to whole microseconds so both sides agree on which moment is even being discussed.

The embarrassing part is why it took hours.

That recorder, the one capturing every question and answer, had a bug of its own. It was dropping the optional settings from most calls it recorded, so roughly 1,500 calls originally made with unusual settings were replayed with defaults.

Our evidence was making our code look better than it was.

That is worse than the code being broken, and it took a beat to feel how much worse. Broken code gets fixed because something tells you. A flattering test setup gets trusted. You see the green number, believe it, and go work on something else. The microsecond bug only became visible after we fixed the recorder. It had been sitting there the whole time behind a score that was lying to us.

Your test setup is code too. Same author, same day, same assumptions as the bug you are hunting. It deserves at least as much suspicion as the thing it tests. Ours got checked last. It should have been first.

Two things the random script found

Sydney, in the year 2100, off by exactly one hour. Exactly one hour is a suspicious number. It usually means you are not lost, you are in the wrong timezone. Both versions produced the same wall clock time and disagreed only on the offset, and ours was wrong for an Australian winter. Neither cron library was at fault. Timezone data lists real daylight saving switches out to about 2037 and then adds a rule saying "keep doing this forever." Python keeps applying that rule indefinitely. The Rust timezone library builds a fixed table and, once past the end of it, holds the last offset forever. They agree until 2099 and part ways in 2100. Nothing to fix, so we pinned the boundary with a test that fails if that library ever extends its table, and capped the random script at 2099 so it stops comparing timezone databases and goes back to comparing cron libraries. Also, if you are scheduling jobs in Australia beyond 2099, your offset may be an hour out. Felt worth mentioning.

A function that took 92 seconds to return its first result. The original walks through scheduled runs one at a time, so asking for the first three only ever computes three. Ours computed all of them into a list and handed the list back. Identical results, every test passed, and nobody would notice because no sane person writes a test asking for a decade of runs. Then the random script generated a year long range at one second resolution. The answers were never wrong, the shape of the work was. On a wide enough range that stops being slow and becomes a crash. It streams now, pinned by a test that pulls three runs out of a ten year window at one second resolution, roughly 300 million results if you were foolish enough to compute them all, and checks it returns immediately.

Random input found a design mistake no hand written test would ever have expressed.

Three bugs we found and deliberately did not fix

While checking our work we came across three open bug reports filed against the original library by other people. We tested all three. We reproduce all three exactly, on purpose.

This feels wrong the first time you type it. You can see the bug, you know the fix, and fixing it is still the wrong move, because the point of the exercise is behaving identically and people downstream may already have worked around it. A rewrite that quietly improves things is a rewrite nobody can safely swap in.

So all three are locked down by tests. If upstream ever fixes one, our test goes red and tells us to look. A deliberate bug with an alarm on it is a decision. Without the alarm it is a bug you got away with.

The receipts

make build          # builds it
make test           # our tests, plus the recorded replay
make test-original  # the original Python suite, run against our version

Or with nothing but Docker:

docker build -t croniter-rs . && docker run --rm croniter-rs

All of it re-runs on every push, including a fresh round of random comparison that fails the build on any disagreement.

Code and full write-ups: https://github.com/moneytosms/croniter-rs

Two files there are worth more than the code. One lists all 19 places we knowingly differ from the original, with reasons. The other lists every bug we found, worst first, plus a security review of the original that came back clean.

If you liked this project then go give it a like on devfolio and check it out here

Built for Port Mortem 2026 by Nidhi Rakesh and Srimoneyshankar Ajith.

@partnerships_raptors At

DEV Community: Srimoneyshankar Ajith