How Can Developers Test a 26:00:00 Schedule Time?
From the earlier reference collection. Read the current software blog.
A focused fixture should verify that 26:00:00 remains a valid service-day value and resolves to 02:00 on the next calendar day.
State what the value means
A schedule parser should treat 26:00:00 as 26 hours after the beginning of the service day, not as an invalid wall-clock time. The GTFS reference describes service days that can exceed 24 hours and uses 26:00:00 to illustrate a trip continuing to 02:00 the following calendar day. [GTFS schedule reference](https://gtfs.org/documentation/schedule/reference/)
Write the expectation first: given a service date of Friday and a time of 26:00:00, a conversion routine should yield 02:00 Saturday in the schedule’s local time context, while preserving Friday as the service date. This makes the intended boundary behavior explicit.
Build a minimal fixture
Create one trip with two stops, one at 25:30:00 and another at 26:00:00. Associate it with a service ID that runs on the chosen Friday. Keep the fixture small enough that a failure points to time parsing or date conversion, not unrelated route data. Include the feed’s time-zone setting if the code resolves local timestamps.
The parser should split the string into numeric fields and calculate 26 × 3,600 seconds. The conversion step then adds that duration to the start of the service date. Avoid converting the hour field to a 24-hour clock before adding the date, since that would erase the following-day relationship.
Assert both representations
Test the numeric value and the resolved date-time separately. The service-day total should be 93,600 seconds. The local event should fall on Saturday at 02:00 for the example service date, and the record should still identify Friday as its service date. If the application stores the raw source string, assert that it remains 26:00:00 after conversion.
A useful negative case is a malformed minute field, such as 26:75:00. The parser should reject it with a clear validation error instead of carrying 15 minutes into the hour. Another boundary case can verify that 24:00:00 becomes midnight on the next calendar day.
Test consumers, not just parsing
Finally, check that downstream behavior respects the result. A timetable sorted by service-day seconds should place 26:00 after 25:30. A calendar display should show the event on Saturday at 02:00, while a trip lookup for Friday’s service pattern should still find the trip.
This fixture protects a small but consequential convention. It catches accidental modulo-24 conversion, date rollover errors, and confusion between calendar date and service date before those mistakes reach a public schedule display.