Volume 2

Q131: Date, Time and Time Zone Handling

Difficulty: SeniorFrequency: HighAnswer time: 8-12 minutes

What Interviewers Want To Evaluate

This question checks whether you understand why date and time bugs are common in JavaScript applications. Interviewers want timestamps, time zones, UTC, local time, parsing, formatting, daylight saving time, storage strategy, date-only values, and frontend/backend contracts.

Senior answers should show caution. Time handling is a product and data-contract problem, not only a Date API problem.

Short Interview Answer

JavaScript Date represents a point in time internally as milliseconds since the Unix epoch. Displaying and parsing that point can involve local time zones, UTC, formats, and daylight saving rules. Store precise instants as UTC timestamps or ISO strings with time zone information. Treat date-only values, like birthdays or due dates, differently from moments in time. Format for users with Intl.DateTimeFormat or a well-chosen library, and define frontend/backend contracts clearly.

Detailed Interview Answer

JavaScript Date is often misunderstood because it combines several concerns:

instant in time
local representation
UTC representation
string parsing
display formatting
calendar rules

A Date object stores an instant. The confusion usually happens when that instant is parsed or displayed.

Date Stores an Instant

const date = new Date("2026-07-25T10:00:00Z");

console.log(date.getTime());

getTime() returns milliseconds since January 1, 1970 UTC.

The same instant can display differently in different time zones.

Local vs UTC Methods

JavaScript has local and UTC methods.

date.getHours();
date.getUTCHours();

getHours uses the runtime's local time zone. getUTCHours uses UTC.

Mixing these accidentally creates off-by-hours bugs.

ISO Strings

toISOString outputs UTC.

const value = new Date().toISOString();

This is useful for API transport when you mean a precise instant.

Example:

2026-07-25T10:00:00.000Z

The Z means UTC.

Parsing Hazards

Date parsing can surprise people.

new Date("2026-07-25");

Date-only strings and browser parsing rules have caused many bugs across apps. Avoid relying on ambiguous string parsing for important workflows.

Prefer explicit contracts:

instant: ISO timestamp with timezone
date-only: YYYY-MM-DD as a plain date concept
time-only: separate local time value

Date-Only Values

A birthday is not the same as a timestamp.

1998-04-12

If you convert a date-only value into a Date at midnight UTC, users in some time zones may see the previous day.

For date-only fields, store and transport the date as a date-only string unless the domain says otherwise.

Daylight Saving Time

Daylight saving time makes local time arithmetic tricky.

Adding 24 hours is not always the same as adding one calendar day in a local time zone.

const nextDay = new Date(date.getTime() + 24 * 60 * 60 * 1000);

This adds 24 hours, not one calendar day.

Calendar math often needs a date/time library or backend support.

Display Formatting

Use Intl.DateTimeFormat for user-facing display.

const formatter = new Intl.DateTimeFormat("en-IN", {
  dateStyle: "medium",
  timeStyle: "short",
  timeZone: "Asia/Kolkata",
});

formatter.format(new Date());

This avoids hard-coded display formats.

Storage Strategy

A practical strategy:

store instants in UTC
store date-only values as date-only strings
store user time zone when local scheduling matters
format at the edge for the viewer
avoid ambiguous parsing
test boundary time zones

For calendars and scheduling, the user's time zone is often part of the data model.

Time Zone Is Product Data

For a meeting scheduled at 9 AM in Bangalore, the time zone matters.

For a server log event, UTC timestamp is usually enough.

For a daily reminder, you need the user's local zone and calendar rule.

The domain decides the representation.

Common Mistakes

A common mistake is storing local display strings in the database.

Another mistake is treating date-only values as timestamps.

Another mistake is testing only in the developer's local time zone.

Senior Trade-Offs

Use native Date for simple instants and formatting with Intl. Use a library or platform API for heavy calendar math, time zones, recurring events, durations, and scheduling.

Do not invent calendar rules manually unless the scope is tiny and tested.

Code or Design Example

function normalizeApiEvent(raw) {
  return {
    id: String(raw.id),
    occurredAt: new Date(raw.occurredAt),
    displayTimeZone: raw.displayTimeZone ?? "UTC",
  };
}

This separates the instant from the zone used for display.

Debugging Workflow

When date bugs happen:

identify whether value is instant or date-only
check stored format
check timezone in API payload
check local vs UTC methods
check date parsing path
test users east and west of UTC
test daylight saving boundaries
verify display formatting locale and zone

Interview Framing

Start by saying Date stores an instant. Then explain UTC storage, date-only values, display formatting, and DST risk.

Revision Notes

Instants, date-only values, local times, and display formats are different concepts. Model them separately.

Key Takeaways

Time bugs happen when product meaning is collapsed into one vague Date object. Define the contract first.

Follow-Up Questions

  1. What does JavaScript Date store internally?
  2. What does toISOString output?
  3. Why are date-only strings tricky?
  4. How do UTC and local methods differ?
  5. Why is DST hard?
  6. When should you store user time zone?
  7. How should dates be displayed?
  8. Why should display strings not be stored as source data?
  9. How would you test timezone bugs?
  10. When should a date library be used?

How I Would Answer This In A Real Interview

I would say JavaScript Date stores an instant, then separate instants from date-only values and local scheduling. I would recommend UTC timestamps for instants, date-only strings for date-only data, Intl for display, and explicit testing around time zones and daylight saving.