Why I ripped out a cron parsing library and wrote my own

Aniket Saini — Fri, 03 Jul 2026 04:13:27 +0000

Building the cron builder for Quietbench, I started with an npm package for parsing and calculating next-run times. Get it working, move on. That lasted about a week.

The problem: the library handled standard cron fine, but broke on real edge cases — conditional OR/AND behavior when day-of-week and day-of-month are combined, step values inside ranges (1-10/2), and off-by-one errors around DST transitions. When I checked its output against standard cron engines, the mismatches showed up fast.

Why not patch it: the parsing and "next run time" logic were tightly coupled internally. Fixing one edge case risked breaking another. Writing something scoped to exactly what I needed was less work than fighting someone else's abstraction.

The rewrite keeps three things cleanly separate: tokenize/validate each field, normalize day-of-week/day-of-month interaction explicitly, and compute next executions by walking forward in time rather than solving algebraically. Slower in theory, irrelevant in practice — nobody notices a few milliseconds when they're reading 5 output times.

Building the cron builder for Quietbench, I started with an npm package for parsing and calculating next-run times. Get it working, move on. That lasted about a week.

The problem: the library handled standard cron fine, but broke on real edge cases — conditional OR/AND behavior when day-of-week and day-of-month are combined, step values inside ranges (1-10/2), and off-by-one errors around DST transitions. When I checked its output against standard cron engines, the mismatches showed up fast.

**The actual lesson: **reaching for a library first isn't wrong. But once I was spending more time reverse-engineering why the library disagreed with standard cron behavior than I would've spent writing the logic myself, that was the signal to just own it.

Live at quietbench.dev/cron-builder — curious if anyone finds an edge case it still gets wrong. reaching for a library first isn't wrong. But once I was spending more time reverse-engineering why the library disagreed with standard cron behavior than I would've spent writing the logic myself, that was the signal to just own it.

Live at quietbench.dev/cron-builder — curious if anyone finds an edge case it still gets wrong.

I built a free, no-signup dev tools site because I was tired of ad-heavy formatters

Aniket Saini — Thu, 02 Jul 2026 14:24:24 +0000

Like a lot of developers, I have a handful of bookmarked utility sites I use constantly — JSON formatter, regex tester, that kind of thing. Over time most of them got slower, ad-heavier, or started asking for signups for basic features.

So I built my own small suite:

JSON Formatter — format/validate/minify, with a tree view for nested objects
Regex Tester — live match highlighting plus a plain-English breakdown of what your pattern does
Cron Builder — visual builder + parser, shows your next 5 execution times
Contrast Checker — WCAG AA/AAA contrast checking with a live preview
API Tester — lightweight Postman-style request tester, no install

Everything runs client-side in the browser — no backend, no data leaves your machine, no account needed.

### A few implementation notes for anyone curious

The cron parser was the one piece I ended up writing from scratch rather than pulling in a library. I wanted predictable behavior for the "next 5 execution times" calculation without dragging in a heavy dependency.

Writing a cron parser from scratch is a trap, though. I immediately hit a subtle bug in how Day-of-Month and Day-of-Week restrictions interact. In standard Unix cron, if both fields are restricted (i.e. not *), the engine treats them as an OR condition, not an AND. My initial logic combined them with an AND operator, which broke schedules like 0 0 1 * 1 (which should run on the 1st of the month or every Monday). I caught it when sanity-checking the next execution times against public standard engines, and had to rewrite the matching logic to correctly handle the conditional OR/AND split.

Built with React + Vite + Tailwind, deployed as a static site.

Would genuinely appreciate feedback — especially if anything looks broken on mobile, that's the area I'm least confident in right now.

https://quietbench.dev

DEV Community: Aniket Saini

Why I ripped out a cron parsing library and wrote my own

I built a free, no-signup dev tools site because I was tired of ad-heavy formatters