Could You Create a GTFS Stop-Time Browser?
From the earlier reference collection. Read the current software blog.
A stop-time browser joins a selected trip to its ordered stop events while preserving GTFS service-day times, including values beyond midnight.
Start with the feed’s relationships
A GTFS stop-time browser is a focused way to explore the connection between trips, stops, and scheduled events. In a typical schedule feed, trips.txt identifies trips and their routes, while stop_times.txt associates a trip with stops, arrival and departure times, and a sequence. The GTFS schedule reference documents these files and fields; use the feed’s actual identifiers when joining them.
Load the relevant files and index trips by trip_id. For a selected trip, gather only stop-time rows whose trip_id matches, then order them by stop_sequence. Do not rely on the order in which rows happen to appear in the CSV. The sequence field communicates the intended order, and it also helps diagnose missing or duplicated rows.
Display service-day time faithfully
A crucial detail is that GTFS times may extend beyond 24:00:00. The specification describes service days that can continue into the following calendar day, using values such as 26:00:00. A browser should display that value as written or provide an equally explicit conversion. Turning it into 02:00 without a next-day indication makes it easy to mistake the event for an earlier time.
For example, a trip with times 23:40:00, 24:15:00, and 26:00:00 should remain in that sequence. A user-facing display might show “23:40,” “24:15 (next calendar day),” and “26:00 (next calendar day).” If the interface converts these to clock time, it should also show the day offset and explain how the service date is applied.
Make selection useful
A minimal browser can offer a trip selector that shows route and headsign alongside a stable trip identifier. If several trips share a route, those additional labels help a user choose the intended run. A search box can narrow the list, but avoid presenting a route name as though it uniquely identifies a trip.
For each selected trip, display a table with sequence, stop name, arrival, departure, and any available pickup or drop-off information that the interface supports. Handle blank times as blank rather than copying the neighboring time unless the data contract explicitly calls for that interpretation. A missing stop identifier or unresolved stop should be visible as a data issue, not silently omitted.
Keep the browser honest
Show the feed name or version used to populate the browser and make clear that these are scheduled times. A static schedule view does not establish real-time vehicle position or guarantee that service is operating. The distinction matters when someone uses the display to understand a feed rather than to make an immediate travel decision.
Test a trip that crosses midnight, a trip with several stops, a missing optional time, and a malformed sequence. Include a case where the source rows are deliberately shuffled to ensure ordering comes from stop_sequence. The result should make the feed’s structure easier to inspect while preserving the unusual details that schedules rely on.