What Is the Safest Way to Round a Departure Time?
From the earlier reference collection. Read the current software blog.
Round a departure only in its presentation, retaining the precise scheduled value for ordering and all downstream calculations.
Keep the source value intact
A published departure time is data, not just text to format. Preserve the source value at its available precision for sorting, comparisons, and calculations. If a screen rounds it to the nearest five minutes, that display choice should not overwrite the underlying scheduled time.
For example, a departure at 8:02 might be displayed as “about 8:00” in a summary, but the detailed timetable should retain 8:02 if that is what the source specifies. Replacing the stored value with 8:00 could change which trip appears first or how a connection is evaluated.
Choose a clear presentation rule
If rounding is useful, state or signal the convention. “About 8:00” communicates approximation better than an exact-looking “8:00.” A rounded value should not imply greater certainty or a different published schedule. For a rider making a time-sensitive connection, retaining exact minutes is usually more informative.
Rounding direction also matters. Rounding down can suggest a departure earlier than scheduled; rounding to nearest can move it either way. A compact overview may use a broad time range, while a detailed list can retain the exact value.
Handle dates and extended times first
Interpret the schedule value in its proper context before formatting it. An extended time such as 25:10 means a position after midnight on the service-day timeline; it should not be rounded as a clock-only string that discards the next-day offset. GTFS schedule values can extend beyond 24 hours. [GTFS schedule reference](https://gtfs.org/documentation/schedule/reference/)
A safe sequence is to preserve the service date and precise time, derive the event’s date and local clock presentation, then apply an explicitly chosen display rounding rule. This keeps a rounded label from changing whether the event belongs to the current or following calendar date.
Keep calculations independent
Use the precise value for ordering, countdowns, and any connection logic. Apply rounding only when rendering a particular screen, and retain enough context to show the exact time when a user needs it. Test boundary cases such as 8:02, 8:03, and 23:59, along with an after-midnight service time.
This separation gives readers a simple summary without compromising the schedule data. A rounded label is a presentation aid; the underlying departure remains the value used by the software.