← Debugging Guides

阅读中文版本

JavaScript Invalid Date — Parsing Produced NaN Time

Fix Invalid Date by using ISO 8601 input, checking Number.isNaN(date.getTime()), and avoiding browser-dependent date string parsing.

beginnerdebuggingjavascriptdateparsing

Symptoms

  • new Date("...") logs as "Invalid Date" and getTime() is NaN
  • Formatting a date yields NaN in the output string
  • Works in Chrome but fails in Safari

Possible causes

  • The string is not a format the engine accepts (especially non-ISO in Safari)
  • Month/day order is ambiguous ("03/04/2024")
  • An invalid value (empty string, null) is passed to the constructor

Diagnosis steps

Check validity explicitly

node -e "const d=new Date("not a date"); console.log(d.toString(), Number.isNaN(d.getTime()))"

Interpretation

getTime() returns NaN for an invalid date; isNaN on it is the reliable validity test.

Prefer ISO input

new Date("2024-03-04T10:00:00Z").toISOString()

Interpretation

ISO 8601 with an explicit timezone parses consistently across engines.

Root cause

The Date constructor accepts ISO 8601 reliably but treats most other strings as implementation-defined. An unrecognized string yields a Date whose time value is NaN, displayed as Invalid Date.

Fix

Normalize input to ISO 8601 (optionally with a timezone), parse explicitly for custom formats, and validate with Number.isNaN(date.getTime()) before use; fall back or throw on invalid input.

Risk note

Relying on Date string parsing for locale formats is non-portable; use a date library or explicit parsing.

Verify the fix

Run the parse on Node and a browser and confirm both report valid; assert getTime() is a finite number in tests.

Symptoms

This debugging guide addresses “JavaScript Invalid Date — Parsing Produced NaN Time”. Start from the symptoms, follow the ordered diagnostics, and confirm each hypothesis before moving on; the fix and verification steps then close the loop.

Observed symptoms include:

  • new Date(“…”) logs as “Invalid Date” and getTime() is NaN
  • Formatting a date yields NaN in the output string
  • Works in Chrome but fails in Safari

Reproduce and Diagnose

Reproduce the failure in isolation before changing any code. Work through the checks below in order; each one narrows the search space.

Step 1: Check validity explicitly

node -e "const d=new Date("not a date"); console.log(d.toString(), Number.isNaN(d.getTime()))"

getTime() returns NaN for an invalid date; isNaN on it is the reliable validity test.

Step 2: Prefer ISO input

new Date("2024-03-04T10:00:00Z").toISOString()

ISO 8601 with an explicit timezone parses consistently across engines.

Likely contributors, in order of frequency:

  • The string is not a format the engine accepts (especially non-ISO in Safari)
  • Month/day order is ambiguous (“03/04/2024”)
  • An invalid value (empty string, null) is passed to the constructor

Root Cause

The Date constructor accepts ISO 8601 reliably but treats most other strings as implementation-defined. An unrecognized string yields a Date whose time value is NaN, displayed as Invalid Date.

The Fix

Normalize input to ISO 8601 (optionally with a timezone), parse explicitly for custom formats, and validate with Number.isNaN(date.getTime()) before use; fall back or throw on invalid input.

Watch out: Relying on Date string parsing for locale formats is non-portable; use a date library or explicit parsing.

function parseDate(input) {
  const d = new Date(input);
  if (Number.isNaN(d.getTime())) {
    throw new RangeError(`invalid date: ${input}`);
  }
  return d;
}

parseDate('2024-03-04T10:00:00Z'); // ISO, reliable
// parseDate('03/04/2024');         // throws -> engine-dependent, avoid

Verify and Prevent

Run the parse on Node and a browser and confirm both report valid; assert getTime() is a finite number in tests.

Once verified, add a regression test that reproduces the original symptom so the failure cannot silently return.

This class of failure is usually environmental rather than pure logic, so capture the exact command, the environment variables, and the working directory in your bug report. Reproduce it in the smallest possible script, then widen the scope only once the minimal case is understood. A short written checklist for this failure mode saves hours the next time it appears.