Skip to main content
Dev Utilities Pro

Methodology · Overview

Methodology

Reviewed by · Last reviewed .

Every calculator on Dev Utilities Pro is a real piece of software with tests, a primary-spec citation, and a named human who reviews it. Here is how the process works, end to end. For category-specific methodology — spec sources, algorithm derivations, edge cases, and platform dialect notes — see the per-category pages linked at the bottom of this page. For how Bedrocka Tools operates as a publisher more broadly, see our editorial standards.

How tools are built

Calculators are written in TypeScript as pure functions inside a shared package (@bedrocka-tools/calc), with Vitest unit tests that cover edge cases: cron expressions that never fire, Y2K38 overflow boundaries, DST transition hours, Base64 padding for 1 and 2 remainder bytes, two's complement for minimum and maximum signed values per bit-width, and every platform dialect quirk we can enumerate. The package has no UI and no side effects — if a calculator gives the wrong answer, there is one file to fix and a failing test that tells us it was wrong.

Spec sourcing — primary sources only

We only cite primary sources. Secondary blog summaries of a spec are not sources. Primary sources we use routinely:

  • IEEE Std 1003.1 (POSIX.1-2017) — crontab specification (§7.3.5), epoch definition (§4.16)
  • RFC 3339 — internet timestamp format
  • RFC 4648 — Base64 data encoding
  • IANA Time Zone Database — 600+ named timezone rules
  • Knuth, The Art of Computer ProgrammingVol. 2, §4.4 — radix conversion algorithms (Horner's method, repeated division)
  • Intel SDM Vol. 1, §4.2 — two's complement integer representation
  • Platform documentation — AWS EventBridge, GitHub Actions, Quartz scheduler, Kubernetes — cited at the specific document URL and section

Review process

  1. Draft: algorithm and explanatory copy are drafted with the primary spec open in parallel and every constant checked against the source document.
  2. Spec review: each calculator is reviewed by Byron Malone against the primary specification. Platform behaviors are verified against platform documentation and, where possible, live-environment outputs.
  3. Citation verification: every URL cited is spot-checked at publish time; every named rule or range is re-checked against the source document.
  4. Publish: with a Last Reviewed stamp and a dateModified schema.org field on every page.

Update cadence

Every calculator is reviewed on a quarterly cadence. We also update immediately on any of the following triggers:

  • A new POSIX or IEEE edition is published that changes a spec behavior we implement
  • An IETF RFC erratum is published affecting our implementation
  • A platform (AWS EventBridge, GitHub Actions, Quartz) changes a dialect behavior we document
  • The IANA timezone database publishes a significant rule update affecting our DST edge-case documentation
  • A user report identifies a material error in a calculator or documented platform behavior

Error reporting

If a calculator gives you the wrong answer — or if platform behavior diverges from what we document — we want to hear. Email info@bedrockatools.com with the tool, the inputs you used, the output you got, and a reference to the relevant spec or platform documentation if you have it. We respond to every report within 3 business days; if the tool is wrong, we fix it and publish a correction note on our corrections page.

Per-category methodology

Each calculator category has a dedicated methodology page covering the primary specifications, algorithm derivations, platform dialect notes, edge cases, and limitations:

  • Cron syntax — POSIX field specification, next-execution algorithm, platform dialect comparison (POSIX, Quartz, AWS EventBridge, GitHub Actions, Kubernetes), special character semantics.
  • Timestamp formats — Unix epoch definition, seconds vs. milliseconds auto-detection, ISO 8601 and RFC 3339 formatting, IANA timezone normalization, Y2K38 computation, reverse conversion algorithm.
  • Number bases — Horner's method (base-N to decimal), repeated division (decimal to base-N), two's complement derivation and validation, Base64 encoding (RFC 4648), ASCII table.

Limitations

Calculators on this site are utilities for estimation. Platform implementations differ — a cron expression that validates correctly per the POSIX spec may behave differently on a specific cron daemon version, and a timestamp conversion correct per POSIX.1-2017 may differ from a language runtime's Date implementation in DST edge cases. Always verify outputs against your actual runtime environment before relying on them in production.