Validate Date Instances in JavaScript: Detect Invalid Dates

You will learn why an invalid date is still a Date object, how JavaScript represents invalid dates internally, and how to write reliable validation functions using getTime() and Number.isNaN().

A JavaScript Date object stores one value: a timestamp measured in milliseconds from January 1, 1970 UTC. A valid date has a finite numeric timestamp.

When construction or parsing fails, JavaScript still creates a Date object, but its internal time value is NaN (Not-a-Number). That is why all of these can be true at once:

const d = new Date("foo");

console.log(d instanceof Date); // true
console.log(typeof d);          // "object"
console.log(d.getTime());       // NaN
console.log(d.toString());      // "Invalid Date"

Therefore, validating a Date instance requires two checks:

1. Confirm the value is a date object.
2. Confirm its timestamp is not NaN.

This matters because invalid dates can silently travel through an application and only fail later—for example, when formatting a date, saving it to an API, or calling .

Think of a Date as a labelled container containing a timestamp.

• A valid Date container holds a number, such as 1714521600000.
• An invalid Date container still exists and still has the Date label, but it holds NaN instead of a usable timestamp.

Checking value instanceof Date verifies the label. Checking value.getTime() verifies that the container holds a real timestamp.

Use getTime() to read the timestamp and Number.isNaN() to test whether it is invalid.

function isValidDate(value) {
  return value instanceof Date && !Number.isNaN(value.getTime());
}

console.log(isValidDate(new Date("2024-05-01"))); // true
console.log(isValidDate(new Date("not a date"))); // false
console.log(isValidDate("2024-05-01"));           // false
console.log(isValidDate({}));                       // false

getTime() returns:

• A number for valid dates.
• NaN for invalid dates.

Consider this example:

const input = "not a date";
const date = new Date(input);

const isDateObject = date instanceof Date;
const timestamp = date.getTime();
const valid = isDateObject && !Number.isNaN(timestamp);

console.log(valid); // false

Step by step:

1. new Date(input) creates a Date object even though the text cannot be parsed.
2. date instanceof Date is true because it is structurally a Date instance.
3. date.getTime() returns NaN because the date has no valid timestamp.
4. Number.isNaN(timestamp) is true.
5. The ! operator changes that to false, so is .

• API boundaries: Reject invalid Date values before serializing request data.
• Form handling: Validate a date produced by a date picker or conversion function before saving it.
• Database writes: Prevent invalid timestamps from being stored in records.
• Scheduling: Ensure an event, reminder, or job has a usable execution time.
• Data imports: Detect malformed dates while processing CSV files or external service responses.

For example, validate before converting to ISO format:

function serializeDate(date) {
  if (!isValidDate(date)) {
    throw new TypeError("Expected a valid Date instance");
  }

  return date.toISOString();
}

In production code, date validation is often placed at boundaries: when input enters a function, API handler, service, or database layer.

A guard clause keeps the main logic simple:

function createAppointment(startsAt) {
  if (!isValidDate(startsAt)) {
    throw new TypeError("startsAt must be a valid Date");
  }

  return {
    startsAt: startsAt.toISOString(),
    createdAt: new Date().toISOString()
  };
}

For applications that receive text input, separate the two responsibilities:

1. Parse or construct a Date from the input.
2. Validate the resulting Date instance.

const startsAt = new Date(userInput);

if (!isValidDate(startsAt)) {
  return { error: "Enter a valid date." };
}

This makes function contracts clear: a function either accepts raw strings and parses them, or it accepts already-created, valid objects.

Checking only instanceof Date

This accepts invalid dates:

function isDate(value) {
  return value instanceof Date;
}

isDate(new Date("bad input")); // true — not enough

Also test the time value.

Comparing getTime() with NaN

NaN is not equal to anything, including itself:

const date = new Date("bad input");

console.log(date.getTime() === NaN); // false

Use Number.isNaN(date.getTime()) instead.

Using global isNaN() without understanding coercion

Global converts its argument to a number first:

// Standard same-realm validation
function isValidDate(value) {
  return value instanceof Date && !Number.isNaN(value.getTime());
}

// Cross-realm-friendly validation
function isValidDate(value) {
  try {
    return !Number.isNaN(Date.prototype.getTime.call(value));
  } catch {
    return false;
  }
}

• Valid Date → date.getTime() is a number.
• Invalid Date → date.getTime() is NaN.
• new Date("invalid") is still a Date object.

Why is new Date("bad value") instanceof Date true?

The constructor still returns a Date object. Its internal timestamp is NaN, which marks it as invalid.

How do I check whether a JavaScript date is invalid?

Use Number.isNaN(date.getTime()). It returns true for an invalid Date.

Is date.toString() === "Invalid Date" safe?

It usually identifies an invalid date, but it is better to check the timestamp with getTime(), which directly tests the date value.

Why does date.getTime() === NaN return false?

By JavaScript rules, NaN is not equal to any value, including another NaN. Use Number.isNaN().

Should my API accept date strings or Date instances?

Either can be appropriate, but choose one contract clearly. Date strings are easier to transmit over JSON; Date instances are convenient inside JavaScript code. Validate at the boundary either way.

• NaN and Number.isNaN() — Needed to correctly test the invalid timestamp value.
• Date parsing with Date.parse() — Relevant when the input is text rather than an existing Date instance.
• ISO 8601 date strings — A useful, predictable format for API date input and output.
• instanceof — Explains constructor-based type checks and their cross-realm limitation.
• Guard clauses — Helps reject invalid values early in functions.
• Error handling with throw — Useful when invalid dates violate a function's contract.
• Date.prototype.toISOString() — Commonly used for API serialization after validation.