How Can a Schedule Reader Detect a Holiday Service Change?
From the earlier reference collection. Read the current software blog.
A reliable holiday check combines the weekday calendar with date-specific additions and removals before deciding which trips operate.
Start with the date’s ordinary pattern
A schedule reader should first identify the service date in the agency’s local calendar. A weekday label by itself is not enough: a holiday that falls on Monday may not follow the ordinary Monday pattern. In a GTFS feed, calendar.txt can describe recurring service by weekday and date range, while calendar_dates.txt can add or remove service on particular dates. The specification defines both files as part of the schedule format. [GTFS schedule reference](https://gtfs.org/documentation/schedule/reference/)
For example, suppose service_id WEEKDAY runs Monday through Friday throughout the published period. The reader checks whether the selected date is within that period and whether its weekday flag is active. That establishes the baseline, not the final answer.
Apply the exceptions
Next, inspect date-specific exceptions for the same service date. An exception that adds service can make a normally inactive service run; one that removes service can suppress a weekday pattern. Apply each applicable entry to its corresponding service_id, then determine which trips refer to active service IDs. Do not treat an exception as a replacement for the whole calendar: it changes the status of the identified service pattern on that date.
A small worked case helps. If the selected Monday is a public holiday and WEEKDAY is normally active, a removal for WEEKDAY means trips using that ID should not be offered. If a separate HOLIDAY service ID has an addition for that date, trips tied to HOLIDAY may run instead. The displayed pattern depends on both results.
Explain the outcome to the reader
A useful interface can say “Holiday schedule” only after it has resolved the active services. If the feed contains no exception, the reader should avoid inventing a holiday rule; the published weekday pattern may be the only available evidence. When the feed is incomplete or the date lies outside its coverage, present that uncertainty rather than silently assuming ordinary service.
Keep the internal result inspectable: record the selected local date, active service IDs, and which exception entries changed the baseline. This makes an apparent missing trip easier to diagnose and helps distinguish a genuine schedule change from a display or time-zone bug.
A practical validation routine
Test a normal weekday, a weekend, a date with removed service, and a date with added service. For each, trace a representative trip back to its service_id and confirm that the trip appears only when that service is active. Also test a date with no matching exception so the ordinary calendar remains effective.
The reader’s final statement should be narrow and useful: identify the service pattern found in the feed and the date it applies to. That gives people a reasoned answer without promising that a schedule file captures every operational change made outside the published data.