What Should a Schedule Export Say About Its Time Zone?
From the earlier reference collection. Read the current software blog.
An export should identify the time zone or explicit offset used to interpret each timestamp, especially when local schedule values become dated events.
A clock reading needs context
A time such as 08:15 does not identify a unique moment. It could refer to different places, dates, and offset rules. A schedule export that presents timestamps without a named time zone or explicit UTC offset leaves downstream readers guessing how to compare or display them.
For a transit schedule, distinguish the feed’s local service-day notation from a fully resolved timestamp. A GTFS time can be expressed relative to a service day, including values above 24:00:00; the reference explains that these can extend into the following calendar day. [GTFS schedule reference](https://gtfs.org/documentation/schedule/reference/)
Choose a clear representation
If the export is meant to preserve the source schedule, include the original service date and time string and state the time-zone identifier used to interpret it. If it emits resolved timestamps, include either a named zone with each applicable date-time or an explicit offset such as -07:00. A named zone is useful for human readers and for applying date-specific clock changes; an offset identifies the relationship to UTC for that particular timestamp.
For example, instead of exporting “2026-08-14 01:30,” provide “2026-08-14 01:30 America/Los_Angeles” or a timestamp carrying the correct numeric offset. The zone name and offset are not interchangeable in every use: an offset does not by itself tell a reader what the zone’s rule will be on another date.
Keep service date and calendar date distinct
When an overnight schedule value is converted, record both the service date that selected the trip and the calendar date of the resulting event. A Friday service time of 26:00 may become 02:00 Saturday locally. An export that keeps only Saturday’s timestamp can make it difficult to reconstruct why the trip was active under Friday’s service calendar.
Name fields plainly: service_date, scheduled_time, local_datetime, and timezone are more informative than a generic date column. Document whether the export’s time is an original feed value or a converted value.
Make the export reusable
Provide a brief schema note with the zone source, the conversion rule for over-24-hour times, and the handling of daylight-saving transitions. If the export mixes agencies, identify the zone per agency or record; one global setting may be wrong for a multi-region dataset.
Finally, test a regular date, a date near a clock change, and an overnight time. A consumer should be able to recover the original service-day event and compare resolved timestamps without guessing. Clear zone metadata makes the file safer to reuse in maps, reports, and timetable applications.