Interview answer drill

Use this JavaScript interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.

Practice interview questions Follow JavaScript mastery study plan Practice more JavaScript interview questions

JavaScript Intl.DateTimeFormat: Time Zones, DST, and Reliable Date FormattingFrontend interview answer

HighIntermediateJavascript

By FrontendAtlas Team · Updated Apr 4, 2026

Interview focus

This JavaScript interview question tests whether you can explain JavaScript time-zone formatting: DST bugs, IANA zones, and Intl.DateTimeFormat, connect it to production trade-offs, and handle common follow-up questions.

JavaScript time-zone formatting: DST bugs, IANA zones, and Intl.DateTimeFormat explanation without falling back to memorized docs wording
Frontend Interview and Date Time reasoning, edge cases, and production failure modes
How you would answer the most likely JavaScript interview follow-up

Practice more JavaScript interview questions

Interview quick answer

Intl.DateTimeFormat solves the production bug of formatting across time zones and DST without unsafe manual offset math. The useful angle is IANA zone IDs, locale formatting, and why fixed offsets break scheduling or audit displays.

Full interview answer

Production bug to avoid

Time-zone formatting gets hard when daylight-saving transitions, locale rules, and business zones differ from the user's machine. Intl.DateTimeFormat exists so you do not ship fixed-offset math that works in March and fails in November.

Core mental model

Store timestamps in UTC, transport as ISO strings, and convert at the presentation edge with an IANA time zone (for example America/New_York). Do not store local wall-clock strings as source-of-truth.

Requirement	Recommended approach	Why
Show user-local time	Intl.DateTimeFormat with user locale + zone	Correct locale grammar and DST handling
Show business-region time	Pass explicit IANA zone in formatter options	Consistent cross-user display
Build custom UI pieces	Use `formatToParts()`	Stable token extraction without brittle regex
Sort/filter by time	Compare UTC timestamps, not formatted strings	Avoid locale-dependent ordering bugs

Keep UTC for logic, Intl formatting for display.

Runnable example #1: stable zone-aware formatting

JAVASCRIPT

const ts = new Date('2026-03-08T09:30:00Z');

const fmt = new Intl.DateTimeFormat('en-US', {
  timeZone: 'America/Los_Angeles',
  year: 'numeric',
  month: '2-digit',
  day: '2-digit',
  hour: '2-digit',
  minute: '2-digit',
  hour12: false
});

console.log(fmt.format(ts));

This safely formats around DST boundaries without hardcoding offsets like UTC-8 or UTC-7.

Runnable example #2: formatToParts for composable UI

JAVASCRIPT

function formatParts(date, locale, timeZone) {
  const parts = new Intl.DateTimeFormat(locale, {
    timeZone,
    weekday: 'short',
    year: 'numeric',
    month: 'short',
    day: '2-digit',
    hour: '2-digit',
    minute: '2-digit'
  }).formatToParts(date);

  return Object.fromEntries(parts.map((p) => [p.type, p.value]));
}

console.log(formatParts(new Date(), 'en-GB', 'Europe/London'));

Pitfall	What goes wrong	Better pattern
Fixed offset math	Breaks during DST transitions	Use IANA zone + Intl formatter
Parsing localized strings	Inconsistent browser behavior	Parse ISO input, format only for output
Using display value for data logic	Sorting/filtering bugs	Keep logic on numeric timestamps
Assuming server timezone	Cross-region inconsistencies	Persist UTC and explicit zone metadata

Most production date bugs are data-modeling mistakes, not syntax mistakes.

Common pitfalls

Storing date-only values as midnight local time and getting off-by-one day bugs across regions.
Rendering with browser default zone when product requirements need business-zone consistency.
Testing only one locale/time zone and missing DST boundary regressions.

When to use / when not to use

Use Intl for display formatting in browser and server-rendered UI. Use timestamp math for calculations and persistence. Do not rely on manually concatenated date strings for mission-critical workflows like billing cutoffs or booking windows.

Interview follow-ups

Q1: Why avoid fixed offsets? A: Offsets change with DST and differ across historical periods.
Q2: How do you test this reliably? A: Add test cases around DST start/end for multiple IANA zones.
Q3: What do you store in database? A: UTC instant plus optional business-zone metadata when needed.

Implementation checklist / takeaway

Persist UTC, format with Intl + explicit IANA zones, validate DST edge cases in tests, and keep display concerns separate from business logic. Strong answers show both correctness and maintainability.