How Should a Public Schedule Tool Treat Invalid Time Values?
From the earlier reference collection. Read the current software blog.
Reject malformed schedule times with a specific diagnostic, and preserve the raw value so the feed can be investigated without silent repair.
Validate before interpreting
A public schedule tool should parse time fields strictly enough to catch malformed values before they affect trip ordering or display. A value such as 08:7:00 may violate the expected representation, and 08:75:00 has an out-of-range minute field. Do not silently reinterpret either as a nearby valid time.
GTFS defines field formats and presence conditions in its reference, so validation should follow the relevant field definition rather than a generic clock parser’s assumptions. Schedule times may also use hours above 24, meaning a parser must distinguish valid extended hours from invalid minute or second values. [GTFS schedule reference](https://gtfs.org/documentation/schedule/reference/)
Report the failure precisely
A useful diagnostic identifies the file, row or record, field name, raw value, and reason for rejection. “Invalid time” alone forces an operator to hunt through a large dataset. A message such as “stop_times.txt, trip T42, stop sequence 6, departure_time 08:75:00: minute value is outside the allowed range” points to the repair location.
Keep user-facing behavior appropriate to the impact. If one trip is invalid, the tool might suppress that trip and expose a data-quality notice, while continuing to serve unaffected schedules. If the defect prevents reliable interpretation of the whole feed, mark the feed unavailable rather than showing potentially misleading times.
Preserve the original field
Store the raw string alongside parsed values and diagnostics. This helps distinguish a publisher’s input from a transformation bug and supports reproducible reports. Avoid overwriting the raw value with a normalized guess, since that destroys evidence and can make the defect difficult to trace.
A repaired or tolerated value should be an explicit policy with an auditable record, not an invisible parser side effect. If the tool cannot infer the intended time safely, rejection is clearer than carrying a malformed value into a rider’s itinerary.
Test malformed and valid boundaries
Create fixtures for a normal time, midnight, an extended service-day time such as 26:00:00, an invalid minute, an invalid second, and a missing field where presence rules allow it. Assert that valid values parse as expected, invalid values generate targeted reports, and raw inputs remain unchanged.
The objective is useful failure: keep valid schedule records available where possible, make defects easy to diagnose, and never present a guessed correction as if it came from the published feed.