"Invalid time value" only in Safari: the date string that is not actually ISO

Problem

Our scheduling UI crashed for exactly one user segment, the Safari users:

RangeError: Invalid time value
    at Date.toISOString (<anonymous>)

Chrome, Firefox, and our Node jobs all accepted the same input string. We did not have a single Safari machine in the office, which is why it survived three weeks of QA.

Root cause

The input looked innocent: '2026-09-06 14:30:00', a space instead of T. The ECMAScript spec only REQUIRES engines to parse the ISO formats like YYYY-MM-DDTHH:mm. Anything else is implementation-defined: Chrome shrugs and parses it, Safari returns an Invalid Date. Calling toISOString() on an Invalid Date throws the RangeError above.

The second trap hides in the formats that DO parse everywhere: a date-only string, '2026-09-06', is spec'd as UTC midnight. On any timezone behind UTC (the Americas) that becomes 7 or 8pm the PREVIOUS day, and your "today" filter silently includes yesterday. Both bugs are date parsing; only one throws.

Fix

Normalize to the required ISO shape before handing a string to the engine:

function parseWhen(s) {
  const iso = s.trim().replace(' ', 'T');   // '2026-09-06 14:30:00' -> ISO-shaped
  const d = new Date(iso);
  if (Number.isNaN(d.getTime())) {
    throw new Error(`unparseable date: ${s}`);
  }
  return d;
}

For date-only input, stop letting the engine choose the timezone:

const [y, m, day] = s.split('-').map(Number);
const d = new Date(y, m - 1, day);  // local midnight, on purpose

The cheap tripwire that would have caught this in CI: run your date-heavy tests on WebKit (Playwright ships it), or at minimum assert !Number.isNaN(new Date(s).getTime()) on every string your API can produce. Two engines disagreeing about date parsing is not an edge case, it is the norm.