How Do You Sort Times That Pass Midnight?
From the earlier reference collection. Read the current software blog.
Clock text alone sorts poorly across midnight; use elapsed service-day values or fully resolved date-time values while preserving the original schedule notation.
Why text sorting fails
Sorting time strings alphabetically works only when the strings share a date and use a consistent fixed-width format. It does not capture an overnight sequence if the entries use ordinary clock notation. For example, a list containing 23:40, 00:15, and 01:10 sorts with the after-midnight entries first, even though they occur later in the trip.
GTFS can represent an overnight time as a value greater than 24 hours. Its reference gives 26:00:00 as a way to describe 02:00 on the following calendar day within one service day. [GTFS schedule reference](https://gtfs.org/documentation/schedule/reference/) That representation provides a natural sort key: elapsed seconds since the service-day origin.
Convert to a numeric key
Parse hours, minutes, and seconds as integers, then compute total seconds: hours multiplied by 3,600, plus minutes multiplied by 60, plus seconds. For a sequence of 23:40:00, 24:15:00, and 26:00:00, the keys increase in the same order as the trip events. The first is 85,200 seconds, the next 87,300, and the last 93,600.
Do not reduce the hour field modulo 24 before sorting. Doing so turns 24:15 into 00:15 and loses the fact that it belongs after 23:40 within the service day. Keep the source string too, so a diagnostic or export can preserve the schedule’s original notation.
Use date-time values when the date matters
If the application needs to compare events across service dates or time zones, resolve each value to a date-time using the service date and the feed’s local time-zone context. A service-day time of 26:00 on Friday can then be represented as 02:00 on Saturday, while retaining Friday as the source service date. Sort these resolved values chronologically for cross-day comparisons.
Avoid mixing numeric service-day seconds with timestamps from unrelated zones. They answer different questions: one orders events within a service day; the other places events on an absolute timeline. Make the chosen ordering explicit in the data model.
Check the sequence with a small fixture
A useful test fixture contains a late-evening stop at 23:40, a post-midnight stop at 24:15, and a later one at 26:00. Assert that parsing produces strictly increasing numeric keys and that conversion maps the latter values onto the next calendar date. Add a malformed value such as 24:75:00 and assert that parsing rejects it rather than normalizing it silently.
The practical rule is simple: sort schedule values as structured time data. Keep raw text for traceability, use service-day seconds for within-day sequence, and use zoned date-time values when calendar chronology is the question.