How Should a Timetable Show an Ambiguous Local Time?
From the earlier reference collection. Read the current software blog.
When a clock change repeats a local time, include enough date, offset, or zone detail for readers to distinguish the two events.
Recognize the repeated hour
In regions that move clocks backward, a local clock time can occur twice on the same calendar date. A timetable that shows only “1:30” may therefore fail to identify which occurrence it means. The two events have different offsets from UTC even though their wall-clock labels match.
This ambiguity matters for real-time comparisons, alerts, and exports that join schedule events to other timestamped data. A system that stores only the local clock string cannot distinguish the first 01:30 from the second.
Include the missing context
For a rider-facing timetable, show the offset or an unambiguous zone abbreviation alongside the repeated time, and include the date. For example, the two occurrences could be labeled 01:30 with different UTC offsets. Use a zone abbreviation only when it is clear to the intended audience; abbreviations can be unfamiliar or shared by multiple regions.
When a schedule originates as a local service-day value, preserve that value and the feed’s zone context before resolving it to a timestamp. GTFS schedule data uses service-day times, and service days can span past midnight, so the service date and the eventual calendar timestamp may both be relevant. [GTFS schedule reference](https://gtfs.org/documentation/schedule/reference/)
Keep machine data unambiguous
For machine-readable exports, use timestamps that carry an explicit offset or pair a local date-time with a named time zone and a defined ambiguity rule. Do not serialize both events as the same bare local timestamp. Retain the original schedule time and service date separately if users may need to trace the result back to the feed.
A useful record might include local_datetime, UTC offset, zone identifier, service_date, and source_time. The exact field names can vary, but each concept should have a clear meaning and should not be collapsed into an unlabeled string.
Test both occurrences
Build a fixture for a date when the local clock repeats an hour. Assert that the two events remain distinguishable after parsing, display, sorting, and export. Check that an alert referring to one event points to the intended instant rather than merely matching the printed clock time.
The goal is not to burden every ordinary timetable with extra notation. Show the offset or zone detail when ambiguity exists, and keep the underlying data precise enough that every consumer can identify the intended event.