What causes "bad result" in oven-sh/bun?

Verify the host clock: `date -u` should show a post-1970 date

oven-sh/bun · error · Error

bad result

Error message

bad result

What it means

Sanity check in the Date.now microbenchmark copied from WebKit's JSTests/microbenchmarks. It sums one million Date.now() return values; epoch milliseconds are around 1.7e12, so a positive sum of that magnitude is guaranteed for a working clock. `sum < 0` therefore means Date.now() itself returned invalid (negative or corrupted) values, not that the benchmark was misused.

Source

Thrown at bench/snippets/date-now.mjs:8

// Copied from WebKit JSTests/microbenchmarks/date-now.js and date-now-elapsed.js.
// Not a mitata benchmark: run directly with `bun date-now.mjs`.
{
  let sum = 0;
  const t0 = performance.now();
  for (let i = 0; i < 1e6; ++i) sum += Date.now();
  const t1 = performance.now();
  if (sum < 0) throw new Error("bad result");
  console.log("Date.now() x 1e6:".padEnd(28), (t1 - t0).toFixed(2), "ms");
}

{
  let sum = 0;
  const start = Date.now();
  const t0 = performance.now();
  for (let i = 0; i < 1e6; ++i) {
    const diff = Date.now() - start;
    if (diff >= 0 && diff < 1e9) sum += diff;
  }
  const t1 = performance.now();
  if (sum < 0) throw new Error("bad result");
  console.log("Date.now() elapsed x 1e6:".padEnd(28), (t1 - t0).toFixed(2), "ms");
}

View on GitHub (pinned to 8c5296ac45)

Solutions

Verify the host clock: `date -u` should show a post-1970 date
Run the same loop under Node to separate a system clock problem from a Bun/JSC problem
If only Bun returns bad values, reduce to `for(...) sum += Date.now()` and report to oven-sh/bun with the output

Defensive patterns

Strategy: validation

Validate before calling

// cheap sanity check before trusting Date.now in this environment
const t = Date.now();
if (!(t > 0) || !Number.isFinite(t)) throw new Error('Date.now returned an invalid value: ' + t);

Type guard

function isValidEpochMs(t) {
  return typeof t === 'number' && Number.isFinite(t) && t > 0 && t < 4102444800000; // 1970..2100
}

Prevention

Validate clock readings once at startup in clock-sensitive code instead of discovering garbage after a long run
Use performance.now() for elapsed-time measurement — it is monotonic and immune to wall-clock corruption
On VMs/containers, verify time sync (date -u, timedatectl) before running timing benchmarks

When it happens

Trigger: Calling Date.now() one million times in a tight loop and accumulating the results when the engine's date implementation returns garbage. The snippet is run directly with `bun date-now.mjs` (it is not a mitata benchmark).

Common situations: A system/VM clock set before 1970-01-01 UTC; broken RTC in a container or sandbox with time virtualization; a JSC Date regression in a custom Bun build.

Related errors

AI-assisted analysis of oven-sh/bun@8c5296ac45 (2026-08-16). Data as JSON: /api/errors/35b8825c48d1e2e1. Report an issue: GitHub.