can1357/oh-my-pi · error · RangeError
Invalid ISO datetime: ${value}
Error message
Invalid ISO datetime: ${value} What it means
parseIsoDateTimeUtc accepts a string intended to be ISO-8601 with UTC semantics (it normalizes a trailing Z). If `new Date(normalized)` yields an invalid time, it throws a RangeError naming the offending value. The library requires unambiguous machine-readable timestamps; it will not guess.
Source
Thrown at packages/mnemopi/src/core/beam/helpers.ts:127
const total = vw + fw + iw;
if (total === 0) return DEFAULT_WEIGHTS;
return [vw / total, fw / total, iw / total];
}
export function normalizeImportance(importance: number | null | undefined, fallback = 0.5): number {
return clamp01(importance ?? fallback);
}
export function normalizeDateUtc(dt: Date): Date {
const time = dt.getTime();
if (!Number.isFinite(time)) throw new RangeError("Invalid Date");
return new Date(time);
}
export function parseIsoDateTimeUtc(value: string): Date {
const normalized = value.endsWith("Z") ? value : value.replace(/Z$/, "+00:00");
const dt = new Date(normalized);
if (!Number.isFinite(dt.getTime())) throw new RangeError(`Invalid ISO datetime: ${value}`);
return dt;
}
export function parseQueryTime(queryTime?: string | Date | null): Date {
if (queryTime == null) return new Date();
if (queryTime instanceof Date) return normalizeDateUtc(queryTime);
try {
return parseIsoDateTimeUtc(queryTime);
} catch {
return parseIsoDateTimeUtc(`${queryTime}T00:00:00`);
}
}
export function parseTimestampFast(
ts: string | null | undefined,
beam?: Pick<BeamMemoryState, "caches"> | null,
): Date | null {
if (!ts) return null;View on GitHub (pinned to 9690622007)
Solutions
- Convert the string to strict ISO-8601, e.g. `2024-01-02T03:04:05Z`.
- Use a date-only value in `YYYY-MM-DD` form, which parseQueryTime special-cases, or append `Z`/an offset yourself.
- Parse with a dedicated library (e.g. Temporal or date-fns) and pass a valid Date to the API instead.
Example fix
// before
parseIsoDateTimeUtc("01/02/2024 3pm");
// after
parseIsoDateTimeUtc("2024-01-02T15:00:00Z"); Defensive patterns
Strategy: validation
Validate before calling
const ISO_RE = /^\d{4}-\d{2}-\d{2}(T\d{2}:\d{2}(:\d{2}(\.\d{3})?)?(Z|[+-]\d{2}:?\d{2})?)?$/;
if (typeof value !== "string" || !ISO_RE.test(value)) throw new Error(`Not ISO-8601: ${value}`); Try / catch
try {
return parseIsoDateTimeUtc(value);
} catch (e) {
if (e instanceof RangeError && e.message.startsWith("Invalid ISO datetime")) {
return new Date(); // or rethrow with user-facing context
}
throw e;
} Prevention
- Store timestamps only in strict ISO-8601 with explicit Z or offset.
- Never persist locale-formatted dates (MM/DD/YYYY) in machine fields.
- Round-trip test any serialization path that produces timestamp strings.
When it happens
Trigger: Calling parseIsoDateTimeUtc (directly or via parseQueryTime/parseTimestampFast) with a string that is not valid ISO-8601, e.g. `"2024-13-45T99:00:00Z"`, `"2024/01/02"`, or an empty string.
Common situations: Timestamps stored with a locale-dependent format (US `MM/DD/YYYY`), human-entered dates, or truncated strings cut off mid-timestamp; also locales where Date parsing differs from expectations.
Related errors
- Invalid ISO datetime: ${value}
- Unknown changelog category: ${raw}
- No JSON payload found in response
- Line numbers in @@ header must be >= 1
- Line hint must be >= 1
AI-assisted analysis of can1357/oh-my-pi@9690622007 (2026-08-31).
Data as JSON: /api/errors/f9e1d60c7198b4dc.
Report an issue: GitHub.