Look at any airline ticket and you'll see two times: a departure and an arrival. Both are printed in local time at their respective airports, and those airports usually sit in different time zones. That single convention explains nearly every "wait, that can't be right" moment travelers have — like a flight from New York to Los Angeles that leaves at 8 AM, lands at 11 AM, and somehow took six hours. Or a flight that leaves Tokyo on Tuesday afternoon and lands in San Francisco on Tuesday *morning*.
Nothing is wrong with the ticket. You're just reading two clocks set to different zones and treating the gap between them as a duration. Once you know how to put both numbers on the same clock, every itinerary becomes plain arithmetic. This guide covers the one rule airlines follow, a repeatable method for computing true flight duration, why and which way the calendar date jumps, and how to do the math across layovers in a third time zone.
The one rule behind every itinerary
Airlines print departure time in the origin airport's local time and arrival time in the destination airport's local time. There is no hidden UTC column on your boarding pass. Both numbers are wall-clock times — what you'd read off a clock hanging in each terminal.
For passengers, this is the right call. When you land in Paris you want to know what Paris clocks say so you can make a connection or meet a ride — not do mental conversion from your origin zone every time you glance at a screen. But there's a catch worth stating plainly:
- The printed gap between departure and arrival is not the flight's duration.
- It's the duration adjusted by the offset between the two zones — sometimes shrinking the flight on paper, sometimes inflating it.
To recover the real flying time, you put both times on one neutral clock. That clock is **UTC** (Coordinated Universal Time), the global reference every time zone is defined against.
Computing true flight duration: the UTC method
This three-step method works for any flight, in any direction, including ones that cross the International Date Line.
1. **Convert departure local time to UTC using the origin's offset. 2. Convert arrival local time to UTC using the destination's offset. 3. Subtract.** Arrival UTC minus departure UTC is the elapsed travel time.
A note on what you're measuring: this gives you gate-to-gate block time, not pure airborne time. Airlines schedule by block time, so it's the number that matches your ticket — and the one you actually care about.
The offset sign is where people slip, so be deliberate:
- **UTC-5** means local time is five hours *behind* UTC, so `UTC = local + 5`.
- **UTC+9** means local is nine hours *ahead*, so `UTC = local − 9`.
In short: a negative offset (the Americas) means you *add* to reach UTC; a positive offset (Europe, Asia, Oceania) means you *subtract*.
Worked example: a westbound flight that looks too short
A flight leaves New York (JFK) at 8:00 AM and arrives Los Angeles (LAX) at 11:00 AM the same day. The printed gap is three hours — impossible for a coast-to-coast flight.
In summer, New York runs on Eastern Daylight Time (**UTC-4) and Los Angeles on Pacific Daylight Time (UTC-7**).
- Departure: 8:00 AM EDT → `8:00 + 4` = **12:00 UTC**
- Arrival: 11:00 AM PDT → `11:00 + 7` = **18:00 UTC**
- Duration: 18:00 − 12:00 = 6 hours
The flight took six hours. The three-hour zone difference (LA is three hours behind New York) hid half of it. Westbound flights always read artificially short for exactly this reason.
Worked example: an eastbound flight that looks too long
Now reverse it. Depart LAX at 11:00 PM, arrive JFK at 7:30 AM the next day.
- Departure: 23:00 PDT → `23:00 + 7` = **06:00 UTC** (next day)
- Arrival: 07:30 EDT → `07:30 + 4` = **11:30 UTC**
- Duration: 11:30 − 06:00 = 5 hours 30 minutes
The printed clock advanced eight and a half hours, but the flight was five and a half. The extra three hours are the eastbound zone shift. It's also why eastbound red-eyes wreck you: you lose sleep *and* hours of clock time at once.
Why the date changes — and which way it jumps
Two separate mechanisms can flip the calendar date on an itinerary. Confusing them leads to hotels booked for the wrong night.
1. Overnight flights (red-eyes). A late departure simply runs past midnight. A 10:50 PM departure landing at 5:40 AM +1 arrives the next calendar day because the trip straddled midnight in real time. That little +1 superscript is the airline flagging the date change — read it every time and copy the implied date into your calendar.
2. Crossing the International Date Line. Flights over the Pacific can change the date with no overnight involved, because the IDL (running roughly along the 180° meridian) is where the calendar resets:
- Westbound across it (e.g., Los Angeles → Sydney): the date jumps forward. Leave Monday night, arrive Wednesday morning.
- Eastbound across it (e.g., Tokyo → Honolulu, or Auckland → Los Angeles): you can land *earlier* on the calendar than you left, arriving the same day or seemingly "before" departure.
The UTC method handles both cases without special rules — that's its real value. As long as you track the date while converting each local time to UTC, the subtraction stays correct no matter how strange the printed dates look.
Date-line worked example
Depart Tokyo (HND) at 5:00 PM Tuesday, arrive San Francisco (SFO) at 10:00 AM Tuesday. It reads like you landed before you left.
Tokyo is **UTC+9 (Japan observes no DST). San Francisco in summer is UTC-7**.
- Departure: 17:00 Tue JST → `17:00 − 9` = **08:00 UTC Tuesday**
- Arrival: 10:00 Tue PDT → `10:00 + 7` = **17:00 UTC Tuesday**
- Duration: 17:00 − 08:00 = 9 hours
A clean nine-hour flight. The "same morning you left" effect is purely a clock artifact of crossing the date line eastbound — the plane never time-traveled.
Layover math across multiple zones
Connections multiply the confusion: each leg has its own pair of zones, and the layover sits in a third place. The safe approach is to **compute each leg independently in UTC, then handle the connection in the layover city's local time.**
Worked itinerary — Chicago → London → Dubai:
- Leg 1: Depart Chicago (ORD) 6:00 PM CDT (UTC-5), arrive London (LHR) 7:30 AM BST (UTC+1) next day.
- 18:00 → 23:00 UTC; 07:30 (+1) → 06:30 UTC (+1). Duration = 7h 30m.
- Layover in London: Onward flight departs LHR 11:00 AM BST. On the ground 7:30 AM to 11:00 AM local = 3h 30m, comfortably above Heathrow's minimum connection time.
- Leg 2: Depart LHR 11:00 AM BST (UTC+1), arrive Dubai (DXB) 9:00 PM GST (UTC+4).
- 11:00 → 10:00 UTC; 21:00 → 17:00 UTC. Duration = 7h.
Two rules fall out of this:
- Measure layover length in the layover city's local time, using the inbound flight's printed arrival and the outbound flight's printed departure. Both are already in that city's zone — no conversion needed. This is the one place the local-time convention works for you.
- Watch layovers that cross midnight. An 11:45 PM arrival connecting to a 6:00 AM departure is a 6h 15m layover spanning two dates. Make sure any lounge access, transit-visa rules, or day-room bookings account for both dates.
A pre-trip reading checklist
Run through this before you trust any itinerary:
- **Identify each airport's time zone, not just the city's** — large countries span several. "Australia" could mean Perth (UTC+8), Adelaide (UTC+9:30), or Sydney (UTC+10).
- **Check DST status for your exact travel dates.** Offsets shift seasonally across most of North America, Europe, and parts of the Southern Hemisphere. A trip in March or November can cross a DST boundary and change the math by an hour. Arizona, Japan, India, and most of the tropics never change — confirm rather than assume.
- Read every +1 / −1 / +2 beside arrival times and write the implied date into your calendar explicitly.
- **Sanity-check the longest leg with the UTC method.** If your computed duration comes out negative or absurd, you mis-signed an offset or missed a date rollover.
- Compare each layover against the airport's minimum connection time, especially when you change terminals or clear immigration.
Tools that remove the guesswork
You can do all of this with arithmetic and a notepad, but converting half a dozen local times to UTC by hand is exactly where one slipped sign cascades into a missed flight. A few [Timezio](https://www.timezio.com) tools cut out the hand-math:
- The **time zone converter** lets you read departure and arrival times side by side against each airport's zone.
- The world clock tracks your layover city alongside home and destination at a glance.
- The **DST checker** confirms whether an offset will shift between the day you book and the day you fly.
The underlying point is that flight times confuse us because they answer a different question than the one we instinctively ask. The ticket tells you *what the local clock will read when you land* — which is exactly what you need on the ground. Duration is a separate calculation. Route both numbers through UTC, and every red-eye, date-line crossing, and three-airport itinerary collapses into plain, checkable arithmetic.