Can You Create a Schedule-Time Converter for Values Above 24 Hours?
From the earlier reference collection. Read the current software blog.
Convert service-day clock notation into a timestamp by anchoring it to an explicitly supplied service date and time zone.
Keep service time separate from calendar time
Some transit schedules represent times after midnight as hours greater than 24. That notation can keep late-night service attached to the service day on which it began. The GTFS schedule reference describes this convention and notes that service days need not match calendar dates exactly.
A converter therefore needs more than a time string. Accept a service date, a value such as 26:15:00, and the applicable time zone. Treat the date as the anchor for hour zero, then add the given duration. Do not first reduce the hour modulo 24, because that loses the service-day offset.
Parse and validate the value
Split the input into hours, minutes, and seconds. Require nonnegative whole hours, minutes from 0 through 59, and seconds from 0 through 59. Convert the parts into a duration: hours times 3,600 plus minutes times 60 plus seconds. Add that duration to midnight on the supplied service date in the chosen zone.
For a service date of 2026-10-28, 26:15:00 means 2:15 a.m. on the following calendar date, but it remains 26 hours after the start of the service date. Showing both the original value and the resulting timestamp helps preserve that distinction. The conversion should reject malformed values such as 24:75:00 rather than normalize them silently.
Make time-zone behavior explicit
The time zone matters when converting local service dates to absolute instants. A daylight-saving transition can make a local clock time ambiguous or nonexistent. A simple teaching tool can display the result as a local date and time without claiming it uniquely identifies an instant; a production converter should define how it handles those transition cases.
Offer explicit input or configuration for the zone and show its name alongside the result. If the user wants UTC, make that an intentional selection rather than interpreting a local schedule as UTC by default. Tests should cover ordinary values, 24:00:00, a value above 24 hours, and invalid minute or second fields.
Preserve the source notation
Avoid replacing the schedule’s original value with the converted one in downstream data. Store or display both: the service-day notation is useful for understanding the published schedule, while the calendar timestamp is useful for comparisons and sorting. This dual representation also makes debugging easier when an agency’s feed is being inspected.
The GTFS reference is a practical companion when implementing this exercise: consult its service-day definition and time-field conventions to keep the converter aligned with the schedule format. The finished program should print the supplied service date, original schedule value, selected zone, and converted result, so another person can reproduce the calculation without guessing at hidden assumptions.