Why Might Two Agencies Define Their Service Days Differently?
From the earlier reference collection. Read the current software blog.
A service day is a scheduling convention, so comparing feeds requires checking their documentation and interpreting times in each feed’s context.
A service day is a schedule concept
A calendar date runs from midnight to midnight in a time zone. A transit service day can use a different boundary because an agency may want an overnight trip to belong to the service pattern that began the previous evening. The GTFS reference notes that service-day definitions vary by agency and that a service day can extend beyond 24:00:00. [GTFS schedule reference](https://gtfs.org/documentation/schedule/reference/)
That distinction matters when two feeds contain a trip at 01:30. One agency might publish it as 01:30 on the new calendar date; another might represent it as 25:30 on the preceding service day. Those values can describe similar clock times while assigning the trip to different service dates.
Why agencies make different choices
An agency’s service boundary can reflect how it organizes operations, publishes its calendar, or describes overnight service to riders. There is no safe basis for assuming that every feed uses the same local convention. A consumer that compares raw time strings across agencies may therefore put a trip on the wrong date or report that it runs under the wrong weekday pattern.
Consider a route whose Friday service continues until 02:00 Saturday. If the feed records 26:00:00 as part of Friday’s service day, the service calendar to check is Friday’s. A second agency might publish a 02:00:00 trip under Saturday’s date. The numeric values and calendar association should be interpreted according to each feed’s model.
Read the feed before converting
Check the feed’s documentation, service calendar coverage, time-zone context, and examples before normalizing times. The GTFS reference defines service day as an agency-dependent period and provides the over-24-hour notation as an example; that is a reason to preserve the service-day value while interpreting it, rather than immediately forcing it into a midnight-based timestamp.
For a comparison tool, keep both the original service-day time and the derived date-time. Store the agency’s service date alongside the converted instant. This lets a display show a local clock time while diagnostics still explain which calendar entry activated the trip.
Make the assumption visible
A robust importer can flag assumptions such as “times above 24:00 are assigned to the prior service date.” It should not apply that rule universally without checking the source’s published convention. If no documentation resolves an unusual pattern, retain the raw value and report the ambiguity instead of quietly changing the trip’s date.
When you present an interagency comparison, label each time with its local date and zone, and explain whether the date refers to calendar day or service day. This small clarification prevents a visually plausible timetable from concealing a different operational interpretation.