How Can You Compare Two Schedule Feed Versions?
From the earlier reference collection. Read the current software blog.
Unpack two feed versions into separate directories, normalize line endings, and diff selected tables before investigating changes.
Prepare isolated copies
Keep each schedule archive intact and extract it into a different, empty directory, such as old/ and new/. This prevents files present only in one version from leaking into the other during comparison. List the archive members first: a publisher may change a directory prefix or omit a table, and a comparison is misleading if you accidentally inspect stale files.
Choose a small set of tables tied to the question. If stop locations changed, begin with stops.txt; if scheduled departures changed, inspect stop_times.txt alongside the tables that identify trips and stops. Comparing every file can generate noise from metadata or generated ordering while obscuring the change you care about.
Normalize line endings, not meaning
Files may use LF line endings on one version and CRLF on another. Convert copies to a common convention before diffing so a whole file does not appear changed merely because line terminators differ. For example, on systems with dos2unix, run it on copied files in both directories, then compare with diff -u old/stops.txt new/stops.txt. Keep the original extracted files untouched if byte-for-byte evidence matters.
Normalization should be limited and explicit. Do not trim whitespace, reorder columns, or sort rows as a first step; those operations can hide meaningful changes or make it harder to trace a difference back to the published bytes. If row ordering is known to be irrelevant, create a separate normalized comparison and document how it was produced.
Interpret a text diff carefully
A unified diff shows changed lines with context, which works well for small tables. Large files may produce huge output, so start with file sizes, headers, and a focused subset. A changed row can reflect a changed value, an added record, a removed record, or simply a different row order. Use a CSV-aware script to compare records by stable identifiers when you need a semantic comparison.
For example, compare stop records by stop_id and then inspect which fields changed for a particular identifier. A plain line diff is still valuable for locating raw edits, but it does not understand that a row represents one entity or that a quoted comma belongs within one field.
Check the feed’s structure
Compare file lists as well as file contents. The absence of calendar_dates.txt in one release, for example, may be a meaningful structural change or a packaging error; it should not be silently ignored. The GTFS schedule reference documents the feed’s table structure and field definitions, giving you a basis for deciding what a missing or altered file means.
End with a concise change note: the two archive identifiers, the tables compared, normalization steps, and notable additions or edits. That record makes a later investigation repeatable and keeps a raw text difference from being mistaken for an explained schedule change.