Airlines are running out of 4-digit flight numbers

Original Article ↗ Hacker News Discussion ↗

Airlines are hitting the limit of 4‑digit flight numbers, especially large U.S. carriers that also assign numbers to thousands of codeshare flights, exposing constraints baked into decades‑old global reservation and air traffic systems. Commenters float obvious technical fixes—adding a fifth digit, using letters or hex, or issuing multiple airline codes—but note that even small format changes would ripple through countless legacy systems, contracts, and safety‑critical workflows worldwide. Many see it less as a numbering problem and more as a coordination and modernization challenge for an industry still deeply tied to 1960s-era technology.

Scope of the Problem

  • Only a few very large airlines (notably in the US) are close to exhausting 4‑digit numeric flight numbers.
  • Main drivers: huge schedules plus thousands of codeshare “marketing” numbers layered on top of partner-operated flights.
  • Flight numbers are used across reservation systems, ATC, airport displays, baggage, revenue, loyalty, etc., so changes propagate widely.

Why “Just Change the Format” Is Hard

  • Many systems assume exactly 4 numeric digits in fixed-width fields (e.g., columns 25–28 in legacy records, PIC 9(4) in COBOL, 1980s controllers for flip-tab displays).
  • Logic often decodes airline codes and flight-number ranges directly (e.g., “if prefix == DL then…”), sometimes in Fortran/COBOL/TPF with no tests.
  • Aviation IT is deeply interconnected worldwide; any change requires global coordination across airlines, GDSs, airports, regulators, vendors.
  • People compare it to Y2K or IPv6: technically straightforward, operationally a huge, slow, risky migration.

Proposed Technical Solutions (and Issues)

  • More space: 5‑digit numbers, alphanumeric (base‑36), or hex. Pros: bigger namespace. Cons: breaks countless assumptions and UIs; many downstream systems would reject non-numeric or longer values.
  • Extra airline prefixes: give big carriers additional IATA codes (e.g., second two-letter code, or use codes of merged airlines). Pros: simple concept, already done in parts of Asia. Cons: heavy legacy coupling to a single code per carrier, possible confusion with branding and procedures.
  • Reuse numbers more aggressively: same number for out-and-back or multi-stop segments, or reuse daily. Already done; some see ID reuse as dangerous, others note the real unique key is number + origin + date, and internal systems already have global unique IDs (e.g., GUFI).

Codeshares as Root Cause and Target

  • Many argue codeshares are the real bloat and confuse passengers; suggest booking only under the operating carrier’s number.
  • Others explain why codeshares persist: single-itinerary booking across airlines, revenue and inventory control, baggage rules, frequent-flyer accrual, legal liability, and government or “flag carrier” requirements.
  • Some think updating booking/loyalty logic to work without separate codeshare numbers might be easier than changing the industry-wide flight-number format; others are skeptical.

Meta and Broader Themes

  • Several comments stress this is mostly a coordination and legacy-safety problem, not an algorithmic one.
  • Comparisons to IPv6, NAT, ISBN and train-number expansions illustrate that “obvious” technical fixes become hard in large, old ecosystems.
  • A minority suggests non-technical “solutions” like reducing flights or breaking up mega-airlines, but these are more rhetorical than concrete.