Days of operation and period expansion: the date math that breaks parsers

Here is the idea that trips up almost every first schedule parser: a flight-leg record doesn’t describe a flight. It describes a pattern — a rule that expands into a set of concrete operating dates. Get the expansion wrong and you silently invent flights that don’t operate, or drop ones that do. Neither error announces itself.

The three fields that define the pattern

A leg’s operating dates are the intersection of three things:

• Period start / end — the date range the row is valid for (a season, or part of one).
• Days of operation — a 7-position field, one slot per weekday (1 = Monday … 7 = Sunday), carrying the day number where it operates and a blank where it doesn’t.
• Frequency rate — for patterns that don’t run every matching week (e.g. every second week).

Days field  "1234567"  → every day
Days field  "12345  "  → weekdays only (Sat/Sun blank)
Days field  "1  4  7"  → Mon, Thu, Sun

Where the bugs hide

• Blank vs zero vs space. The days field distinguishes “operates” from “doesn’t” by position and character. Read a blank as a zero, or misalign the field, and the whole weekly pattern shifts.
• Inclusive edges. Is the period-end date itself an operating day? Off-by-one at the first or last date is one of the most common expansion errors.
• Frequency rate. “Every second week” patterns need a reference point; drop the frequency and you double the flights.
• DST and the day boundary. Expansion produces dates, but overnight flights and daylight-saving shifts mean a “date” and a “moment” aren’t the same thing — the two problems interact.
• Season rollovers. At the summer/winter boundary, a series may end mid-week; the last real operating date isn’t always the period end.

The file gives you a compact rule. The truth is the fully expanded set of dates — and the compression is exactly where the mistakes hide.

Doing it right

Correct expansion means intersecting the period, the day-of-week mask, and the frequency into an explicit, inclusive set of operating dates — then reconciling it with the time and DST handling so each date maps to the right moment. It’s unglamorous, it’s easy to get 95% right and 5% wrong, and that last 5% is what strands a passenger.

Doing it deterministically, the same way every time, is precisely the kind of thing SSIM Toolkit exists to take off your plate — so “which dates does this flight actually operate?” is a reliable answer, not a source of quiet drift.