The data-quality edge cases that break schedule parsers

Everyone who has written a schedule parser has the same arc: it works on the first file, breaks on the second, and by the tenth it’s a thicket of special cases. The SSIM format is simple; real feeds are not. Here’s a field guide to the edge cases that do the damage — and why the fix is judgement, not just code.

The usual suspects

A field guide

Time mode and UTC offsets. The carrier record declares whether times are local or UTC. Assume the wrong one and every departure is off by hours. Even in local mode, each station’s offset matters when you compare across time zones.

Overnight arrivals (the day change). A red-eye departs one day and arrives the next. SSIM signals this; a parser that ignores the day-change indicator computes a negative flight time or lands the aircraft before it left.

Daylight-saving transitions. Within a single scheduling season, clocks change. A flight’s local time stays constant while its UTC time shifts across the DST boundary — the changeover weekends are a classic source of “why is this one flight an hour off” bugs.

Operational suffixes. Flight numbers can carry a letter suffix to distinguish related operations. Strip it or mishandle it and two distinct flights collide into one.

Days-of-operation encoding. The field is position-based (1 = Mon … 7 = Sun), with blanks where a day doesn’t operate. Blank vs zero vs space, and the frequency-rate field for every-other-week patterns, are all easy to misread — and a wrong day pattern silently invents or drops flights.

Period and season edges. A series is valid over a date range; expanding it into actual operating dates — inclusive of the right first and last dates, respecting the days of operation — is where off-by-one errors hide.

Segment-data attachment. Segment records (type 4) attach to the preceding leg. Associate them with the wrong leg and codeshares and restrictions scatter across the schedule.

Trailer mismatch. The trailer carries counts. If your parsed totals don’t match it, something upstream is wrong — the format is telling you, if you’re listening.

Why the fix is judgement, not just code

Here’s the trap. Most of these aren’t bugs in the file — they’re conventions. A carrier pads a field a particular way; an operational suffix means something specific; a legitimate overnight looks alarming until you know it’s normal. A parser that treats every deviation from the narrowest reading of the spec as an error drowns the user in false positives. A parser that ignores them silently corrupts the data.

The middle path — the one that actually works — is validation that knows the industry: surface the genuine problems, recognise the established conventions as informational rather than fatal, and let a human suppress a known quirk once instead of fighting it on every file.

The goal isn’t zero warnings. It’s trustworthy warnings — a short queue where every item is worth a human’s attention.

Doing it well

This is the difference between a parser and a tool. SSIM Toolkit is built around exactly this distinction: parse faithfully, expand dates and days correctly, keep segment data attached to the right leg, check against the trailer — and, crucially, tell real errors apart from the real-world conventions that only look like errors, so legitimate feeds come back clean and the issues that remain are the ones that matter.

Next: the airline planning cycle — where all this data comes from, end to end.