Time Zones Are a System Design Problem

A flight departs New York at 11 PM on March 20th. It arrives in Tokyo at 2 AM on March 22nd. That's not a 27-hour flight. The flight is about 14 hours. The date jump happens because Tokyo is 14 hours ahead of New York, and the departure is late at night.

Which time do you show the traveler? Both. Departure in New York time, arrival in Tokyo time. That's what travelers expect because it matches the physical reality: you're at JFK at 11 PM local time, and you land at Narita at 2 AM local time.

This sounds straightforward until you try to implement it in a system that processes, stores, compares, sorts, and displays times across dozens of time zones simultaneously. The bugs are everywhere, and they're the kind that don't show up in testing because your test data is probably all in one time zone.

Store UTC, display local

This is the foundational rule that prevents chaos, and we follow it with zero exceptions.

Every timestamp in our database is UTC. Departure times. Arrival times. Booking creation times. Notification schedules. Chat message timestamps. Everything. UTC.

When we display a time to a traveler or to the AI agent's response, we convert from UTC to the appropriate local time at that moment. "Your flight departs at 11 PM" is a conversion from the stored UTC timestamp to New York time for the departure, and "arriving at 2 AM" is a conversion to Tokyo time for the arrival.

The time zone context is stored alongside the timestamp. A departure time record includes the UTC timestamp and the departure airport's time zone identifier (like "America/New_York"). An arrival time includes the UTC timestamp and the arrival airport's time zone identifier ("Asia/Tokyo").

Storing the time zone identifier rather than the offset is important. "UTC-5" is the offset for New York in winter, but "UTC-4" is the offset in summer. The time zone identifier "America/New_York" captures this correctly regardless of season. The time zone database handles daylight saving transitions.

"Next Thursday" is harder than it sounds

When a traveler says "Find me a flight next Thursday," what date is that? It depends on what time zone the traveler is in. If it's Tuesday night in New York (11 PM ET), "next Thursday" is in two days. But in Tokyo, it's already Wednesday afternoon. "Next Thursday" is further away.

Our AI agent resolves relative dates based on the traveler's current time zone, which we infer from their device or their most recent location data. "Next Thursday" gets resolved to a specific ISO 8601 date before any tool call happens.

This resolution is critical for flight searches. The travel data API needs an exact date. If we resolve "Thursday" wrong by one day, the search results are for the wrong day, and the traveler might book a flight that departs a day earlier or later than intended.

Notification scheduling across zones

A departure reminder should arrive at a useful time relative to the traveler's situation. "Your flight departs in 24 hours" is helpful at 11 PM when the flight is at 11 PM tomorrow. It's not helpful at 3 AM when the traveler is asleep.

We schedule notifications using the traveler's current time zone, not the departure airport's time zone, not the server's time zone, and not the traveler's home time zone. The current zone is what matters because that's where their phone's clock is.

For a traveler who's already at the destination, the current zone is the departure airport's zone. For a traveler still at home, the current zone is their home zone. For a traveler in transit (layover in a third country), it's the layover zone.

The quiet hours enforcement uses the same current-zone logic. Don't wake someone up for a non-critical notification regardless of which time zone the server is in.

Daylight saving transitions

This is the edge case that breaks real systems. A flight is booked for November 3rd at 1:30 AM in the US. Daylight saving time ends that day. 1:30 AM happens twice: once in EDT, then clocks fall back, and 1:30 AM happens again in EST.

Because we store times in UTC, this ambiguity doesn't exist in our database. The UTC timestamp is unambiguous. The conversion to local time handles the transition correctly because we use time zone identifiers, not fixed offsets.

But the display can confuse travelers. A booking made before the DST transition might show a different local time than expected if the display code gets the transition wrong. We test DST edge cases explicitly in our evaluation suite: bookings that span a DST transition, flights that depart during the "fall back" hour, and notifications scheduled near the transition boundary.

Half-hour and quarter-hour offsets

Not all time zones are whole-hour offsets from UTC. India is UTC+5:30. Nepal is UTC+5:45. The Chatham Islands are UTC+12:45. These break any implementation that assumes time zones are integer hours.

We don't do time zone math ourselves. We use the standard time zone database and libraries that handle all offsets correctly. Any manual calculation like "add 5 hours for India" is wrong. It's 5 hours and 30 minutes. And during some historical periods, it was different. Don't do time zone math by hand. Use the library.

Date line crossings

A flight from Auckland to Honolulu departs on March 20th and arrives on March 19th. The traveler goes back in time by crossing the international date line. This is correct and expected, but it confuses display logic that assumes arrival dates are always equal to or after departure dates.

We handle this by never comparing local dates directly. All chronological sorting and comparison happens in UTC. In UTC, the Auckland departure is before the Honolulu arrival. The fact that the local dates appear to go backwards is a display consideration, not a data issue.

The AI agent handles this naturally. "Your flight departs Auckland at 10 PM on March 20th and arrives in Honolulu at 2 PM on March 19th, gaining back a day as you cross the date line." The agent explains the time mechanics because travelers find it confusing.

Audit your time zone handling

If you're building a travel platform, run these test cases:

A trip spanning three or more time zones. Are departure and arrival times shown in the correct local times?

A flight that crosses the date line. Does the arrival date appear before the departure date correctly?

A booking made before a DST transition for a flight after the transition. Is the displayed departure time correct?

A notification scheduled for a traveler in UTC+5:30. Does it arrive at the right local time?

A traveler who says "Thursday" at 11 PM in New York. Is the resolved date correct?

Each of these has broken a real production system at some point. If yours handles all of them correctly, you're in good shape.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.