What Test Catches Transit Times Beyond Midnight?
From the earlier reference collection. Read the current software blog.
Test service-day time arithmetic with a value such as 25:15 and verify its next-day calendar result.
Treat service time as an offset
A transit time like 25:15 is not necessarily malformed. In schedule data, a service day can extend past midnight, so the value can mean one hour and fifteen minutes after the following midnight relative to the service date. A useful test protects that interpretation from code that incorrectly restricts hours to the range 00 through 23.
Pick a clear service date, such as a Tuesday, and parse 25:15 as an offset from the start of that service day. Assert both the resulting date and time: Wednesday at 01:15. Checking only the hour would miss a conversion that forgot to advance the date.
Use neighboring cases
Test 23:59, 24:00, and 25:15 together. The first should remain on the service date, the second should land at midnight on the next date, and the last should land at 01:15 the next day. These values reveal common boundary mistakes, including treating 24:00 as invalid or rolling the date forward twice.
Also test a value with minutes that make arithmetic less visually obvious, such as 26:40. The expected result is two days and 02:40 after service-day start. Keep the expected calendar date in the assertion so the test documents the model rather than just the formatting.
Separate parsing from timezone display
First test conversion to an elapsed duration or service-day offset. Then test how the application displays that instant in the agency's timezone, if it performs that step. Combining the two can make a failed assertion hard to interpret: a correct 25-hour offset may appear under another clock date after timezone conversion, especially near daylight-saving changes.
Use a date far from a clock change for the basic arithmetic case. Add a separate timezone test for daylight-saving behavior, with an explicitly defined policy. This keeps a simple rollover regression from depending on environmental timezone settings.
Check invalid input deliberately
A parser should also have a documented response to malformed values: reject them, return a structured error, or skip them under a known policy. Test that behavior with missing digits or an impossible minute field rather than silently converting bad input to midnight.
This small group of assertions gives future maintainers a concrete rule: schedule hours may exceed 23, and date rollover follows elapsed service-day time. If the underlying format or application contract changes, update the expectations alongside the implementation.