How to handle the transition between published GTFS schedules

The MTA publishes our base GTFS files here. Each MTA agency has their own cadence for publishing GTFS files that corresponds to mode:

• Subway - Roughly twice per year.

• Buses - Roughly four times per year.

• Long Island Rail Road - Every few days or so.

• Metro-North Railroad - Every few days or so.

Some consumers use an automated pipeline to grab our GTFS files and deploy them into their app. This usually works for Long Island Rail Road and Metro-North Railroad, where the GTFS file includes all schedules for the next month or more, regardless of whether or not there's a schedule change in between.

For subways and buses, we replace the old schedule with the new one about a week before the new schedule goes into affect. Automated consumers have historically had challenges around the transition. Apps sometimes show the new schedule prematurely, or say that some routes aren't running.

Merge or hold GTFS

We ask that you do not manipulate the calendar.txt or calendar_dates.txt to extend the effective dates of any schedules. Instead, we encourage you to adopt one of the following strategies to mitigate any issues. This should get the best information to your users:

• Hold newly-published datasets until they become active, and deploy them on that date.

• Use a GTFS merge tool to prepare a merged GTFS dataset spanning the current and future timetables. There are several tools available for merging GTFS datasets, including:

  • The OneBusAway GTFS Merge utility.

  • Google's merge.py.