JavaScript Date Parsing: The Pitfalls That Catch Everyone

JavaScript Dates Are a Minefield

The reason we built a dedicated date converter instead of telling people to "just use JavaScript" is that JavaScript's date handling is genuinely broken in ways that catch even experienced developers. We've seen production bugs caused by every single pitfall described in this guide — some of them in our own code during development.

The core issue is that new Date(string) and Date.parse(string) have behavior that is implementation-defined for most input formats. The ECMAScript spec only mandates how to parse one specific format (a simplified ISO 8601). Everything else — MM/DD/YYYY, June 29, 2024, 2024-06-29 14:30 — is up to the browser or runtime. Chrome, Safari, Firefox, and Node.js all handle these differently. Silently. With no errors.

What the Spec Actually Guarantees

ECMAScript specifies exactly one input format for Date.parse() and the Date constructor:

YYYY-MM-DDTHH:mm:ss.sssZ

This is a simplified profile of ISO 8601 with these rules:

YYYY-MM-DD — date-only form, treated as UTC (not local time — this is different from ISO 8601 itself, which treats date-only as local time).

YYYY-MM-DDTHH:mm:ss.sss — date-time without timezone, treated as local time.

YYYY-MM-DDTHH:mm:ss.sssZ — date-time with Z, treated as UTC.

YYYY-MM-DDTHH:mm:ss.sss±HH:mm — date-time with offset.

That's it. Anything that doesn't match this pattern is parsed in an implementation-defined way. The spec literally says: "If the String does not conform to that format, the function may fall back to any implementation-specific heuristics or implementation-specific date formats."

The Timezone Trap: Date-Only vs. Date-Time

This is the single most common JavaScript date bug, and it's baked into the specification:

// Date-only → treated as UTC
new Date("2024-06-29")
// → Sat Jun 29 2024 00:00:00 UTC
// → Fri Jun 28 2024 20:00:00 in New York (UTC-4)

// Date-time without Z → treated as LOCAL time
new Date("2024-06-29T00:00:00")
// → Sat Jun 29 2024 00:00:00 in your local timezone
// → different UTC instant depending on where you are

// Date-time with Z → treated as UTC
new Date("2024-06-29T00:00:00Z")
// → Sat Jun 29 2024 00:00:00 UTC (always)

The consequence: new Date("2024-06-29") and new Date("2024-06-29T00:00:00") produce different results even though they look like they should represent the same moment. The first is midnight UTC. The second is midnight local. If you're in New York, they're 4–5 hours apart.

This trips up a shocking number of applications. A user's birthday entered as 2024-06-29 gets parsed as UTC midnight, which is June 28th in US timezones. The user sees the wrong date. We've personally watched this bug ship in three different production systems.

Browser Inconsistencies

Here's where it gets worse. These are real parsing differences between current engines:

new Date("2024-06-29 14:30:00") (space instead of T)

Chrome and Firefox parse this as local time (treating the space as a T substitute). Safari historically returned Invalid Date for this format, though recent versions have improved. Node.js accepts it. The spec says nothing about it — this is purely implementation-dependent.

new Date("06/29/2024") (US format with slashes)

All major browsers parse this as June 29, 2024 in local time. But this is convention, not specification. The spec makes no guarantees about slash-separated dates.

new Date("29/06/2024") (European format)

Chrome returns Invalid Date. Some older Firefox versions tried to parse it (and got it wrong). There is zero spec support for day-first formats.

new Date("June 29, 2024") (named month)

All current browsers accept this, but the spec doesn't require it. It's a legacy behavior inherited from the original Netscape JavaScript engine.

new Date("2024-6-29") (single-digit month)

Chrome and Firefox accept this. Strict ISO 8601 parsers would reject it (months must be zero-padded). Safari's behavior has varied across versions.

new Date("2024-06-29T14:30") (no seconds)

Most current browsers accept this. It's technically outside the spec's defined format (which requires seconds), but it's widely supported in practice.

The Two-Digit Year Trap

new Date("01/02/50")
// Chrome: January 2, 1950 (treats 50 as 1950)
// What you probably meant: January 2, 2050

new Date("01/02/30")
// Chrome: January 2, 2030 (treats 30 as 2030)

new Date("01/02/49")
// Chrome: January 2, 2049

new Date("01/02/50")
// Chrome: January 2, 1950 ← the cutoff varies by engine

Browsers use a heuristic to decide whether a two-digit year is in the 1900s or 2000s. The cutoff varies. This is why two-digit years in date strings are dangerous — the interpretation is literally guesswork by the engine.

What to Use Instead

Option 1: Parse ISO 8601 only (the safe minimum)

If you control the input format, always use full ISO 8601 with an explicit timezone designator. This is the only format that the spec guarantees:

// Safe — fully specified
new Date("2024-06-29T14:30:00Z")        // UTC
new Date("2024-06-29T14:30:00-04:00")   // with offset

// Dangerous — ambiguous timezone behavior
new Date("2024-06-29")                   // UTC (spec says so, but surprising)
new Date("2024-06-29T14:30:00")          // Local time (also surprising)

Option 2: Parse manually

For non-ISO formats, the safest approach is to parse the components yourself and construct the Date with explicit UTC values:

// Parse "06/29/2024 02:30 PM" manually
function parseUSDateTime(str) {
  const match = str.match(
    /^(\d{1,2})\/(\d{1,2})\/(\d{4})\s+(\d{1,2}):(\d{2})\s*(AM|PM)$/i
  );
  if (!match) return null;

  let [, mo, d, y, h, min, ampm] = match;
  h = +h;
  if (ampm.toUpperCase() === 'PM' && h !== 12) h += 12;
  if (ampm.toUpperCase() === 'AM' && h === 12) h = 0;

  return new Date(Date.UTC(+y, +mo - 1, +d, h, +min));
}

// This is exactly what our converter does — custom parsers for each
// of the 20+ formats, so there's no ambiguity about what's expected.

Option 3: Use Temporal (the future)

The Temporal proposal (currently at Stage 3 in TC39 as of early 2026) is designed to fix JavaScript's date handling. It introduces proper types for dates, times, time zones, and durations:

// Temporal — explicit, unambiguous
Temporal.PlainDate.from("2024-06-29")         // Date only, no timezone assumption
Temporal.ZonedDateTime.from("2024-06-29T14:30:00[America/New_York]")  // Explicit zone
Temporal.Instant.from("2024-06-29T18:30:00Z") // UTC instant

// Duration arithmetic that handles DST correctly
const dt = Temporal.ZonedDateTime.from("2024-03-10T01:00:00[America/New_York]");
dt.add({ hours: 2 });  // → 2024-03-10T04:00:00[America/New_York] (skips the gap)

Temporal isn't widely available in browsers yet, but polyfills exist (@js-temporal/polyfill), and it's expected to land in engines soon. If you're starting a new project and can tolerate a polyfill, Temporal is the right long-term choice.

Option 4: Libraries (date-fns, Luxon, Day.js)

If you need to parse arbitrary date formats today without writing custom parsers:

// date-fns — lightweight, tree-shakeable
import { parse, format } from 'date-fns';
const result = parse('06/29/2024', 'MM/dd/yyyy', new Date());

// Luxon — full timezone support via IANA
import { DateTime } from 'luxon';
const dt = DateTime.fromFormat('06/29/2024 2:30 PM', 'MM/dd/yyyy h:mm a', {
  zone: 'America/New_York'
});

// Day.js — minimal, Moment.js-compatible API
import dayjs from 'dayjs';
import customParseFormat from 'dayjs/plugin/customParseFormat';
dayjs.extend(customParseFormat);
const d = dayjs('29.06.2024', 'DD.MM.YYYY');

All three are well-maintained and explicit about what format they expect. Unlike new Date(), they won't silently guess.

The Invalid Date Problem

When Date.parse fails, it returns NaN. When the Date constructor fails, it returns a Date object whose toString() is "Invalid Date" and whose getTime() is NaN. The problem is that the Date object is still truthy:

const d = new Date("garbage");
if (d) {
  console.log("This runs! The Date object is truthy even when invalid.");
}

// Correct check:
if (!isNaN(d.getTime())) {
  // Valid date
}

// Or more concisely:
if (d instanceof Date && !isNaN(d)) {
  // Valid date
}

Forgetting this check is how invalid dates propagate silently through a system. The Date object looks real, passes type checks, and only blows up later when you try to format it or do arithmetic.

The Month Indexing Trap

This one isn't about parsing strings, but it causes so many bugs that it belongs here:

// January is 0, not 1
new Date(2024, 0, 1)   // → January 1, 2024
new Date(2024, 1, 1)   // → February 1, 2024
new Date(2024, 12, 1)  // → January 1, 2025 (silently rolls over!)

// Days are 1-indexed (of course)
new Date(2024, 0, 0)   // → December 31, 2023 (rolls back)
new Date(2024, 0, 32)  // → February 1, 2024 (rolls forward)

// Zero-indexed months + 1-indexed days + silent rollover
// = guaranteed bugs if you're not careful

JavaScript inherited this from Java's java.util.Date, which inherited it from C's struct tm. It's a decades-old design mistake that can never be fixed without breaking the web.

Quick Reference: Safe vs. Dangerous

Pattern	Safety	Why
new Date("2024-06-29T14:30:00Z")	Safe	Full ISO 8601 with explicit UTC
new Date("2024-06-29T14:30:00-04:00")	Safe	Full ISO 8601 with explicit offset
Date.UTC(2024, 5, 29, 14, 30)	Safe	Explicit components, UTC, no parsing
new Date("2024-06-29")	Tricky	Parsed as UTC midnight (often unexpected)
new Date("2024-06-29T14:30:00")	Tricky	Parsed as local time (differs by machine)
new Date("06/29/2024")	Dangerous	Implementation-defined, no spec guarantee
new Date("June 29, 2024")	Dangerous	Legacy format, no spec guarantee
new Date("29/06/2024")	Broken	Invalid in most engines
new Date("2024-06-29 14:30:00")	Dangerous	Space separator not in spec, Safari issues

Related Guides

For a deep dive into the ISO 8601 format that JavaScript actually specifies, see ISO 8601 Date Format Explained. For the relationship between JavaScript's Date.now() and Unix timestamps, see What Is a Unix Timestamp?. If you're dealing with DST transitions in JavaScript, see Daylight Saving Time: The Developer's Nightmare. For a comparison of all date format patterns across languages, see the Date Format Cheat Sheet.