Departure and arrival times in a SSIM leg are local. Subtract them directly and a cross-timezone flight looks impossibly short, long, or negative. The correct block time goes through each end's UTC variation — here's the method, with a worked example.
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.
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.
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:
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.
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.
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.
Block time isn’t a display curiosity. It feeds the numbers people plan on:
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.
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.
Almost every serious schedule-data bug is, at bottom, a time bug. Local vs UTC, per-station offsets, and daylight-saving transitions turn a simple 'departure time' into one of the trickiest fields in the file.
Weekly frequencies and seats are the first figures anyone wants from a schedule — and the ones most often wrong. The traps behind the numbers, and why they matter.
An SSIM schedule can be wrong without ever raising an error. What goes wrong in real files, what it costs downstream, and why validation has to come first.