Intl.DateTimeFormat vs moment.js Performance Comparison

Q: Does Intl support every moment.js format token?

No. moment uses token strings like MMM Do, YYYY; Intl uses a declarative options object. There is no 1:1 mapping, so complex layouts require composing options or reconstructing output from formatToParts(). Map each moment token to its Intl equivalent systematically during migration.

Q: How do I migrate a large codebase off moment.js?

Incrementally. Use a static-analysis tool to locate moment imports, replace formatting calls with cached Intl formatters behind a feature flag, monitor latency and errors, then move date arithmetic to Temporal before deleting the dependency.

A cached Intl.DateTimeFormat instance formats dates roughly 5–10× faster than moment().format() and adds 0KB to your bundle — but an uncached Intl formatter recreated per call is slower than moment, so the win lives entirely in the caching pattern. This is a focused recipe under Mastering Intl.DateTimeFormat Options.

Why This Comparison Is Tricky

The naive benchmark lies in both directions. If you write new Intl.DateTimeFormat(...).format(date) in the loop you are measuring, you measure ICU locale-data parsing and rule compilation on every iteration — and Intl "loses" to moment by a wide margin. If instead you hoist the constructor outside the loop, you measure pure formatting in native C++ bindings, and Intl wins by an order of magnitude. The same library appears 35× slower or 7× faster depending purely on where the constructor lives. Any comparison that does not separate construction from formatting is meaningless.

The second subtlety is timezone behaviour: base moment (not moment-timezone) silently uses the host offset, so a benchmark run on a UTC CI box hides the correctness gap that bites in a browser. Pin an explicit zone in both libraries before comparing.

The timeline below shows the two execution paths — construct-then-format-many versus construct-per-format — so it is obvious where the cost accumulates.

Minimal Working Benchmark

The shortest honest comparison hoists the cached formatter and isolates the uncached path so the construction cost is attributed correctly.

import { performance } from 'perf_hooks';
import moment from 'moment';

const DATE = new Date('2024-03-15T14:30:00Z');

// Built ONCE outside the loop — the production pattern.
const cached = new Intl.DateTimeFormat('en-US', {
  year: 'numeric', month: 'short', day: '2-digit',
  hour: '2-digit', minute: '2-digit', timeZone: 'UTC',
});

const run = (label: string, fn: () => string, n = 1_000_000) => {
  for (let i = 0; i < 10_000; i++) fn();        // warm-up triggers tiered JIT compilation
  const t = performance.now();
  for (let i = 0; i < n; i++) fn();
  console.log(label, (performance.now() - t).toFixed(0) + 'ms');
};

run('cached Intl', () => cached.format(DATE));   // ~120ms
run('uncached Intl', () =>                        // ~4200ms — re-parses CLDR per call
  new Intl.DateTimeFormat('en-US', { timeZone: 'UTC' }).format(DATE));
run('moment.js', () => moment(DATE).utc().format('MMM DD, YYYY HH:mm')); // ~850ms

Representative Node.js 20 numbers (1M iterations): cached Intl ~120ms, moment ~850ms, uncached Intl ~4,200ms. The ordering — cached Intl ≪ moment ≪ uncached Intl — is stable across machines even when absolute numbers shift.

Full Production Version

The headline performance result is that Intl.DateTimeFormat is fast when you reuse the formatter and slow when you reconstruct it, and this single fact dominates any comparison with Moment. Constructing an Intl.DateTimeFormat does real work — resolving locale data, building the format pattern — so calling new Intl.DateTimeFormat(...).format(x) inside a loop pays that cost on every iteration and can look slower than Moment. Hoist the formatter out of the loop (or cache it in a module-level map keyed by locale and options) and the per-format call becomes very cheap, typically beating Moment while shipping zero bundle bytes.

Beyond raw speed, the production case for Intl over Moment is bundle size and maintenance: Moment adds a substantial dependency (and its locale files) to your bundle and is in maintenance mode, whereas Intl is built in. So the honest comparison is not just "which format call is faster" but "which total cost is lower" — and once the formatter is cached, Intl usually wins on both runtime and payload. Where you genuinely need Moment-only features during a migration, isolate them behind a boundary so they can be removed as you port to Intl and Temporal.

In real code you want a validated, cached formatter that pins the zone and degrades safely, so the fast path is also the correct path.

type FmtOpts = Intl.DateTimeFormatOptions;
const cache = new Map<string, Intl.DateTimeFormat>();

function getFormatter(locale: string, opts: FmtOpts): Intl.DateTimeFormat {
  // Key includes locale + every option so distinct configs never collide.
  const key = locale + '|' + JSON.stringify(opts);
  let fmt = cache.get(key);
  if (!fmt) {
    fmt = new Intl.DateTimeFormat(locale, opts); // compiled once, reused thereafter
    cache.set(key, fmt);
  }
  return fmt;
}

export function formatTimestamp(
  ms: number,
  timeZone = 'UTC',
  locale = 'en-US',
): string {
  let zone = timeZone;
  try {
    new Intl.DateTimeFormat(locale, { timeZone: zone }).format(0); // probe the IANA id
  } catch {
    zone = 'UTC'; // unsupported zone / stale tzdata — fall back rather than throw
  }
  return getFormatter(locale, {
    year: 'numeric', month: 'short', day: '2-digit',
    hour: '2-digit', minute: '2-digit',
    timeZone: zone,
    timeZoneName: 'shortOffset', // surface DST/STD offset so output is unambiguous
  }).format(new Date(ms));
}

// DST fall-back in New York: 01:30 occurs twice, but a UTC instant resolves to one string.
console.log(formatTimestamp(1699165800000, 'America/New_York'));
// e.g. 'Nov 05, 2023, 01:30 AM GMT-4'

For DST-safe arithmetic (adding days/months across a transition) Intl is the wrong tool — move that to Temporal.ZonedDateTime.add(), covered in date arithmetic without mutations.

Verification Snippet

import assert from 'node:assert';

// Caching must not change output — same string as a fresh formatter.
const opts: Intl.DateTimeFormatOptions = { dateStyle: 'medium', timeZone: 'UTC' };
const a = getFormatter('en-US', opts).format(new Date('2024-03-15T00:00:00Z'));
const b = new Intl.DateTimeFormat('en-US', opts).format(new Date('2024-03-15T00:00:00Z'));
assert.strictEqual(a, b); // identical output, just faster

// The two fall-back instants render the same local time, different offsets.
const f = new Intl.DateTimeFormat('en-US', {
  timeZone: 'America/New_York', hour: '2-digit', minute: '2-digit', timeZoneName: 'shortOffset',
});
assert.strictEqual(f.format(new Date('2023-11-05T05:30:00Z')), '01:30 GMT-4');
assert.strictEqual(f.format(new Date('2023-11-05T06:30:00Z')), '01:30 GMT-5');
console.log('all assertions passed');

Common Pitfalls

The first pitfall is benchmarking Intl unfairly by constructing the formatter inside the measured loop, which measures construction rather than formatting and makes Intl look slow; cache the formatter and measure the format call. The second is ignoring bundle cost in the comparison — Moment's runtime speed is only half the story, and its payload (library plus locales) is a real, recurring cost that Intl avoids entirely. The third is micro-optimizing formatting that is not on a hot path; for most UIs, formatting a handful of dates per render is negligible either way, and correctness and bundle size matter more.

A fourth pitfall is assuming Moment and Intl produce identical strings — they follow different formatting conventions and locale data, so a migration may shift some output; verify the rendered results, do not just swap the calls. A fifth is holding onto Moment for date math under the guise of performance when Temporal is the correct modern tool for arithmetic; separate the formatting comparison from the arithmetic migration. Cache formatters, count the bundle, and benchmark the real call, and the comparison is both fair and favorable to Intl.

Benchmarking the uncached path and concluding Intl is slow.

dates.map(d => new Intl.DateTimeFormat('en-US').format(d)); // wrong: re-parses CLDR per row
const fmt = new Intl.DateTimeFormat('en-US');               // right: hoist once
dates.map(d => fmt.format(d));                               // reuse the compiled instance

Assuming moment is tree-shakable. It mutates global locale state at import, so bundlers cannot drop locales — a minimal SPA inherits ~300KB uncompressed. Intl is a host feature and adds 0KB.
Relying on implicit offsets. Base moment uses the host offset; Intl requires an explicit IANA timeZone. Always pass the zone (and use moment-timezone if you must stay on moment).
Using Date.prototype.toLocaleString() in hot paths. It builds a throwaway formatter per call; cache an Intl.DateTimeFormat instead.

Frequently Asked Questions

Is Intl.DateTimeFormat actually faster than moment.js?

Yes — but only when the formatter is cached. A reused instance runs in native V8/SpiderMonkey C++ bindings and is roughly 5–10× faster than moment().format() in tight loops. Recreating the formatter on every call is the opposite: ICU initialization makes it slower than moment, which is why so many ad-hoc benchmarks reach the wrong conclusion.

Does Intl support every moment.js format token?

No. moment uses token strings like MMM Do, YYYY; Intl uses a declarative options object. There is no 1:1 mapping, so complex layouts require composing options or reconstructing output from formatToParts(). Map each moment token to its Intl equivalent systematically during migration.

How do I migrate a large codebase off moment.js?

Incrementally. Use a static-analysis tool to locate moment imports, replace formatting calls with cached Intl formatters behind a feature flag, monitor latency and errors, then move date arithmetic to Temporal before deleting the dependency.

Is Intl.DateTimeFormat faster than Moment.js?

Yes, when you reuse the formatter. Constructing an Intl.DateTimeFormat is comparatively expensive, so building one inside a loop can look slower than Moment, but hoisting it out (or caching per locale and options) makes each format call very cheap and typically faster than Moment — while shipping zero bundle bytes. The common benchmarking mistake is constructing the formatter inside the measured loop, which measures construction, not formatting.

Why prefer Intl over Moment beyond raw speed?

Because Intl is built into the platform, so it adds no bundle weight, while Moment ships a substantial library plus locale files and is in maintenance mode. The honest comparison is total cost — runtime plus payload plus maintenance — and once the Intl formatter is cached, Intl usually wins on both runtime and bundle size. For date arithmetic, Temporal is the modern replacement rather than Moment.

How do I benchmark date formatting fairly?

Cache the formatter once and measure only the repeated format call, rather than constructing a new Intl.DateTimeFormat inside the timed loop, which measures construction instead of formatting. Also account for bundle size, not just runtime, since a library's payload is a real recurring cost. And verify that migrated output matches, because Intl and Moment follow different conventions and some rendered strings may differ.

Mastering Intl.DateTimeFormat Options — the parent guide to the options object.
Intl API & Legacy Date Patterns — the section overview.
Date arithmetic without mutations — where to move moment's arithmetic.
Legacy date methods vs modern alternatives — the broader case for dropping legacy date code.