Block time, done right: computing it UTC-correct

Block time — the gate-to-gate duration of a flight — looks like a subtraction. Arrival minus departure. It is a subtraction, but of the wrong two numbers if you take the times straight off the SSIM leg. Those times are local, and local minus local is meaningless across a time-zone boundary. Here’s how to do it correctly, and why it’s the same problem as everything else that touches time in a schedule.

Why the direct subtraction lies

A flight-leg record gives you a departure time at the origin and an arrival time at the destination. Both are station-local wall-clock times. The two stations can be hours apart. Subtract the raw clock readings and you’re subtracting times measured on two different clocks — as if two people in different cities timed the flight by looking at their own kitchen walls.

Depart LHR 0930   (local)
Arrive JFK 1230   (local)
Naive: 1230 − 0930 = 3h 00m     ← London to New York in three hours. It isn't.

The real flight is around eight hours. The naive answer is short by exactly the five-hour offset between the two stations — because it never accounted for the fact that New York’s clock runs behind London’s. Go the other way (eastbound) and the same mistake makes the flight look too long, or with an overnight, negative.

The fix: go through UTC

Every SSIM leg carries, for each end, a UTC variation — the station’s offset from UTC on that date, as a signed ±HHMM. That field is the bridge. The method is three steps:

1. Convert departure to UTC: local departure − departure UTC variation.
2. Convert arrival to UTC: local arrival − arrival UTC variation.
3. Subtract in UTC, and if the result is negative, add a full day (1440 minutes) to account for the overnight day change.

Both ends are now on the same clock — UTC — so the difference is a true elapsed duration.

Local times tell you when a flight feels like it leaves and lands. UTC tells you how long it actually took. Block time is a UTC question wearing local clothes.

A worked example

Take that London–New York leg. Departure is 0930 at LHR with a UTC variation of +0100 (British Summer Time). Arrival is 1230 at JFK with a UTC variation of −0400 (Eastern Daylight Time).

Depart LHR  0930 local,  variation +0100  →  0930 − 0100 = 0830 UTC
Arrive JFK  1230 local,  variation −0400  →  1230 − (−0400) = 1630 UTC

Block = 1630 − 0830 = 8h 00m

Eight hours, which is right — versus the three hours the naive subtraction gave. The entire correction came from putting both ends through their UTC variation before subtracting. Nothing about the flight changed; only the arithmetic got honest.

The wrap, and the overnight

Now an eastbound overnight. Depart JFK 2200 local (variation −0400), arrive LHR 1000 local next day (variation +0100).

Depart JFK  2200 local,  −0400  →  2200 + 0400 = 0200 UTC (next calendar day in UTC)
Arrive LHR  1000 local,  +0100  →  1000 − 0100 = 0900 UTC

Raw: 0900 − 0200 = 7h 00m

That one comes out clean, but the general case doesn’t. When converting to UTC pushes the arrival’s clock below the departure’s — which happens whenever the flight crosses midnight UTC — the subtraction goes negative. The correction is to add 1440 minutes:

If (arrival_utc − departure_utc) < 0:  block = (arrival_utc − departure_utc) + 1440

This is the same day-change handling that governs overnight flights, applied in UTC instead of local time. Skip it and a perfectly ordinary red-eye reports a negative block.

Why it’s worth the discipline

Block time isn’t a display curiosity. It feeds the numbers people plan on:

• Rotations. Chaining an aircraft’s legs into a day of flying — rotations and tail assignment — needs the block time of each leg to know when the aircraft is next free.
• Ground time and connections. The gap between one flight’s arrival and the next’s departure — the basis of minimum connect time and turnaround analysis — is only correct if both flanking times are on the same clock.
• Capacity as seat-hours. Any duration-weighted capacity measure multiplies seats by block time. A wrong block scales the error straight into the totals.

And because every one of these leans on the same UTC conversion, one shortcut early — subtracting local times “just to get a rough number” — propagates everywhere. It’s the core lesson of the time-zone minefield: normalise to UTC internally, keep the local values for display, and never compute a duration in local time.

Doing it right

The method, in one breath: convert both ends to UTC using each leg’s UTC variation, subtract, add 1440 minutes on the wrap. It’s a handful of operations, and it turns “three hours to New York” into eight.

SSIM Toolkit computes block time this way as a matter of course — through each end’s UTC variation, with the midnight wrap handled — so a cross-timezone flight shows a sensible duration, an overnight comes back positive, and the rotations, connection, and capacity views built on top all inherit a block time that reflects reality rather than the clock on the wall. More on SSIM Toolkit.