Intl.DateTimeFormat vs. Temporal.ZonedDateTime for DST-Safe Time Zone Conversion in TypeScript

Direct Answer

For regional scheduling logic that mutates dates (add days, find next occurrence, shift across DST transitions), Temporal.ZonedDateTime is the sounder default today. Its .add({ days: 1 }) applies the target zone's rules directly, while Intl.DateTimeFormat only formats — day arithmetic requires a fragile mutate-format-parse round-trip.

For pure display formatting, Intl.DateTimeFormat remains the sounder default: zero dependencies, universal support, and identical DST output for the same ICU version.

A user-level branded IanaZone type with a runtime allowlist is worth layering onto either choice. It catches typos (e.g., 'Asia/Kolkatta') at startup for ~2–3 KB gzipped (full IANA list) or less for a curated regional subset. The guard only works if you enforce it via a constructor-only module export or lint rule; as IanaZone bypasses it.

Runtime ICU/tzdata differences do shift the comparison. The polyfill bundles its own tzdata (IANA 2024a in current 0.4.x), while Intl uses the host ICU. In the same process, the same instant can format differently between the two APIs. Pick one authority per application.

Why Temporal Wins for Scheduling Arithmetic

Temporal.ZonedDateTime stores the instant, the zone, and the calendar. .add({ days: 1 }) advances the wall-clock date in that zone, respecting DST transitions, skipped hours, and repeated hours. Example: in America/New_York on 2026-11-01 (fall-back), adding one day to 01:30 EDT preserves 01:30 EST the next day.

Intl.DateTimeFormat has no arithmetic. To shift a scheduled time by one day you must:

1. Parse the formatted string back to a Date (lossy, ambiguous near transitions)
2. Mutate the Date (adds 24×60×60×1000 ms, not "one day in zone")
3. Re-format with Intl to get the new wall time

This round-trip fails silently when the mutated instant lands in a different offset.

Type Safety Gap: Both APIs Are Stringly-Typed

Intl.DateTimeFormatOptions.timeZone and the polyfill's declarations both type the zone as string. A misspelled IANA ID passes tsc --strict and throws RangeError only when the formatter or Temporal.ZonedDateTime is constructed — typically at first request in production.

Branded IanaZone Guard (Recommended)

// iana-zone.ts
export type IanaZone = string & { readonly __brand: unique symbol };

const ALLOWLIST = new Set<string>([
  // curated subset for your deployed regions, or load from IANA zone.tab
  'America/New_York',
  'America/Los_Angeles',
  'Europe/London',
  'Asia/Kolkata',
  'Asia/Tokyo',
  'Australia/Sydney',
  // ...
]);

export function toIanaZone(input: string): IanaZone {
  if (!ALLOWLIST.has(input)) {
    throw new Error(`Invalid IANA zone: ${input}`);
  }
  return input as IanaZone;
}

// usage
const zone = toIanaZone(config.timeZone); // throws at startup if typo
const fmt = new Intl.DateTimeFormat(undefined, { timeZone: zone, hour: 'numeric' });
const zdt = Temporal.ZonedDateTime.from(`2026-10-12T12:00:00Z[${zone}]`);

Cost: ~2–3 KB gzipped for the full IANA list (~600 zones). A curated subset for your markets is smaller. Enforce via eslint-plugin-import rule blocking direct string literals in zone positions.

ICU/tzdata Variance: The Hidden Divergence

If your application uses both APIs, the same timestamp can render different wall times. Choose one:

• Intl-only: Run Node with --icu-data-dir pointing to a current ICU build, or require Node ≥ 20 (ICU 73+).
• Temporal-only: Accept the ~25 KB gzipped polyfill; its bundled tzdata is your single source of truth.

Verification Checklist

1. Confirm polyfill tzdata version: npm ls @js-temporal/polyfill → check package.json or release notes for IANA version.
2. Test a DST transition edge case (run in Node 18, 20, 22 and target browsers):

   const instant = '2026-11-01T06:00:00Z'; // America/New_York fall-back
   console.log('Intl:', new Intl.DateTimeFormat(undefined, { timeZone: 'America/New_York', hour: 'numeric', hour12: false }).format(new Date(instant)));
   console.log('Temporal:', Temporal.ZonedDateTime.from(`${instant}[America/New_York]`).add({ days: 1 }).toString());
   

3. Validate branded guard at startup: const zones = new Set(Intl.supportedValuesOf('timeZone')) — note this matches host ICU, not Temporal's bundled data.

One Missing Diagnostic Detail

What is your minimum supported runtime? If you must support Node < 20, older browsers, or a locked-down WebView where polyfill globals are forbidden, Intl is your only viable path without a custom build step. In that case, invest in a robust mutate-format-parse helper and the branded IanaZone guard.