Time zones, UTC and DST: the schedule's quiet minefield

If you collect the schedule-data bugs a team hits over a year and sort them by root cause, an uncomfortable share come back to the same thing: time. A departure time looks like the simplest field in the record. It is not. Here’s why the humble timestamp is where so much goes wrong.

Three ways to misread one time

A time in a schedule is meaningless until you know three things about it: is it local or UTC, what’s the station’s offset, and does daylight saving apply on the date in question. Get any one wrong and the same characters mean a different moment.

• Local vs UTC (the time mode). The carrier record declares whether the file’s times are local or UTC. Assume the wrong mode and every time in the file is off by hours. This is the single highest-impact time bug.
• Per-station offset. In local mode, “0600” at SYD and “0600” at LHR are ten-plus hours apart. To compare, sequence, or compute a flight’s duration, you must convert each station’s local time to a common reference using its UTC offset.
• Daylight saving. Offsets aren’t constant. Within one scheduling season, clocks shift. A flight’s local departure can stay “0600” while its UTC time moves by an hour across the DST boundary — and not every country changes on the same date, or at all.

Local "0600" at SYD, 1 Jul   →  UTC 2000 (prev day)   (UTC+10)
Local "0600" at SYD, 1 Jan   →  UTC 1900 (prev day)   (UTC+11, AEDT)
Same field, same airport — one hour apart because of DST.

Where it bites

• Negative or impossible durations. Compute arrival − departure without handling the day change or the offset and you’ll “land” an aircraft before it left.
• Broken connections. Minimum connect time is a gap between two times at one airport. If one flight is read in the wrong mode, the gap — and the connection’s validity — is wrong.
• DST-weekend anomalies. “Why is this one flight an hour off, but only in winter?” is the classic symptom of a mishandled daylight-saving transition.
• Cross-timezone sequencing. Sorting a multi-station schedule by “time” without normalizing to UTC scrambles the true order of events.

A time in a schedule isn’t a number. It’s a number plus a mode plus an offset plus a calendar — and all four have to be right at once.

Doing it right

The reliable approach is to normalize to UTC internally, carrying each station’s offset and its DST rules for the relevant dates, while preserving the original local values for display. Every comparison — durations, connections, overlaps — happens in the common reference; every presentation happens back in local. That’s exactly the discipline a deterministic engine should enforce so you never have to remember it per query.

This is core to how SSIM Toolkit reads a file: honour the declared time mode, apply the right offset and DST for each date, and expand times correctly — so a “0600” means the same moment every time you ask.

Next in the technical series: days of operation and period expansion — the other half of the date-math problem.