How Should Software Parse Times Greater Than 24:00?
From the earlier reference collection. Read the current software blog.
Parse extended transit times as a service-day offset plus a time of day, preserving their original schedule meaning.
Do not force the value into a clock
Many clock and date libraries expect an hour from 0 through 23. A transit schedule can use a larger hour value to place an event after midnight while keeping it on the same service-day timeline. Treating 25:10 as invalid loses information; reducing it to 01:10 without retaining the day offset loses meaning.
A robust representation has at least two parts: the number of whole days after the service date, and the time within that calendar day. For 25:10, those are one day and 01:10. Keep the service date as a separate field.
Parse into elapsed time
One approach is to parse the hour and minute components as integers and compute total minutes: 25 × 60 + 10 = 1,510 minutes. Divide by 1,440 minutes per day: the quotient is one day, and the remainder is 70 minutes, or 01:10. This method also handles a value such as 48:05 as two days plus 00:05, if the input format allows it.
Validate the structure before conversion. Reject missing components, nonnumeric values, and minutes outside the allowed range. Do not silently wrap the hour modulo 24: wrapping converts 25:10 to 01:10 and erases the crucial next-day relationship.
Keep source and display values distinct
Store the original schedule value or a precise elapsed duration alongside its service date. At display time, derive the calendar date and local clock label. For a Friday service date and 25:10, the display can read “Saturday, 1:10 a.m.” or “25:10 (Saturday 1:10 a.m.),” depending on the audience.
This separation also helps sorting. Sorting the original elapsed values places 24:50 before 25:10, while sorting clock labels alone could incorrectly group 00:50 with other calendar-day events. GTFS describes service-day times that can run beyond 24:00. [GTFS schedule reference](https://gtfs.org/documentation/schedule/reference/)
Test the boundary cases
Include examples at 23:59, 24:00, 24:01, and 25:10. Verify that 24:00 becomes midnight on the next date, while the original service date remains available. Test formatting, ordering, and conversion separately so a user-facing label cannot corrupt calculations.
The guiding rule is simple: an extended schedule time is elapsed time from a service-day origin. Preserve its offset through parsing and calculation, and convert it to an ordinary local clock only when the program has enough date and time-zone context to do so.