Why Do Published Schedule Times Need Seconds?
From the earlier reference collection. Read the current software blog.
Retaining seconds preserves the source schedule’s precision and ordering, even when a rider-facing display chooses to round to minutes.
Preserve what the feed says
A schedule field may include hours, minutes, and seconds. If an importer immediately drops seconds, two events that differ in the source can become indistinguishable. Later calculations, sorting, validation, and comparisons then operate on altered data rather than the published value.
GTFS defines time fields in a structured schedule dataset, including examples with seconds and hours beyond 24. Preserving the source representation helps retain the meaning of those fields. [GTFS schedule reference](https://gtfs.org/documentation/schedule/reference/)
A worked ordering example
Imagine two events at 08:12:10 and 08:12:45. A display rounded to minutes may show both as 08:12, but the underlying order is still clear: the second event follows the first by 35 seconds. If both are truncated to 08:12:00 during import, that difference is lost and a later process cannot recover it.
The same issue appears when checking timepoint sequences, comparing a schedule revision, or generating a machine-readable export. Full precision allows the application to decide where rounding belongs, rather than forcing every consumer to inherit the importer’s choice.
Separate storage from presentation
Store parsed time as a numeric duration or another representation that preserves seconds, and retain the raw feed string for diagnostics. A rider-facing display can format selected values at minute precision if that is appropriate for the product. Keep the full value available for computations and indicate the display convention in the interface or documentation.
Be careful about rounding rules. Rounding 08:12:45 to the nearest minute can produce 08:13, while truncation yields 08:12. Neither should happen accidentally through string slicing. Choose a policy that suits the display and apply it consistently.
Validate precision at the edges
A parser test should include nonzero seconds, midnight boundaries, and an over-24-hour value such as 26:00:00. Confirm that sorting and date conversion preserve the intended sequence. A round-trip test can parse a value and serialize it without losing its seconds or changing its service-day hour.
Retaining source precision does not require overwhelming riders with seconds in every screen. It gives the schedule system enough information to calculate accurately, while leaving each interface free to present a simpler view with deliberate, documented rounding.