Documenting the Limits of a Public Schedule Search
From the earlier reference collection. Read the current software blog.
Explain a schedule search’s coverage, time assumptions, and known omissions so readers can judge whether a result answers their actual departure-planning question.
Name what the search covers
State which services, locations, and dates are included, and how coverage is determined. If the search uses a published schedule rather than real-time vehicle positions, say so plainly. A result can accurately reflect a timetable and still differ from what happens on the day of travel.
Avoid broad claims such as “all transit” unless the scope supports them. If certain operators, stops, accessibility details, or fare rules are missing, list those omissions in terms a rider can act on. A reader should know when to consult another source before relying on a result.
Explain time conventions
Tell readers which time zone is used and whether the displayed value is local to the stop. Clarify how dates and trips crossing midnight are treated. In some schedule formats, service-day times can go beyond 24:00; a displayed time after midnight may belong to the previous service day. GTFS documentation describes this convention, but a search interface may use a different source or presentation.
Also say whether times represent scheduled departures or predictions. Do not call a value “live” unless the system actually has current operational data and a defined basis for that label. A short example can prevent confusion: a trip listed as 25:10 on Friday’s service day may correspond to 01:10 on Saturday’s clock.
Describe search behavior
Explain how the search chooses transfers, whether it applies a minimum connection time, and what happens when no itinerary is found. If walking between stops is omitted, state that; if the search returns only a limited number of options, tell the reader how results are ordered or truncated.
Separate a valid “no matching trip” result from unavailable data or a failed search. Readers need different next steps: change the time or locations for the former, try later or consult another source for the latter.
Tie the limits to a decision
Use a concrete question to assess the page: “Can I reach the station by 08:30 on Sunday, with one transfer and enough time to change platforms?” Then check whether the documentation explains the date, time zone, transfer assumptions, and coverage needed to interpret the answer. If a required detail is unknown, label it as unknown instead of implying certainty.
A public schedule lookup offers a practical setting for this exercise. Its page can illustrate a departure-planning task, while GTFS is relevant only when the search’s underlying schedule follows that specification. The documentation should help a reader decide when the result is sufficient and when to verify elsewhere.