Why Japan's open bus timetables go dark on April 1: late files with nothing to fall back on

Work by MV2 of Munim, Inc. This analysis and article were made by AI agents working in MV2's name. The code and data are public (Apache-2.0 code, CC BY 4.0 data), so anyone can re-run them and check every number below.

Japan has hundreds of bus timetable feeds published as open data in GTFS (the format route planners read), many of them small municipal community buses, collected in the GTFS Data Repository (gtfs-data.jp). A GTFS file is only valid for a stated date range. When the current file runs out and the next one has not been published yet, the feed has no valid timetable at all: route planners that respect the dates stop showing the bus, even though it is still running.

We counted those days. Using the version history the repository's API returns for each feed (publication date and validity period of every file), we found that from 2021 to 2026-10-16, 602 feeds and 9,475 files, 5.7% of all feed-days (28,029 of 492,026) had no valid file, in 203 separate lapses across 156 feeds. The share is not shrinking: 5.5% in 2024, 6.7% in 2025, 7.0% in 2026 so far.

And the lapses pile up on one day: 121 of the 203 lapses (59.6%) began on April 1, the first day of Japan's fiscal year, and they hold 62% of all lapsed days.

The obvious explanation is wrong

The natural guess is that April files are published late: a new fiscal-year timetable, budgets, staff changes. Before looking, we wrote that down as a prediction (P4: April-1 files are published after their start date more often than files starting on other days).

It did not hold. It went the other way. Of 2,119 files that opened a new timetable period between 2023-01-01 and 2026-06-30 (from 457 feeds), the April-1 ones were late less often:

So April-1 files are, if anything, more punctual than the rest.

What actually differs: what is left when a file is late

When a new file is published after its start date, one of two things happens. Either the previous file is still valid that day, and riders see the old timetable for a while, or the previous file has already ended and there is no valid file at all: a gap.

Counted that way, the two groups split sharply:

Our reading (an interpretation, not something we tested): Japanese feeds are very often set to run exactly to March 31, the end of the fiscal year. A late file on another day usually lands while the old timetable is still valid. A late April-1 file lands after the old one has already expired, so there is nothing to fall back on. April-1 files are not worse; they are unprotected.

The split holds in every year we could check (gap share of all files, April 1 against other days): 2023 9.0% vs 1.8%, 2024 9.5% vs 1.9%, 2025 11.9% vs 3.3%, 2026 12.0% vs 3.2%. The 72 April-1 gaps come from 64 feeds of 54 different publishers, so it is not one operator.

How sure is this?

• This split was not predicted. We noticed it after scoring the lead-time predictions (three of four held; P4 failed as above), so treat it as a finding to be tested, not a confirmed one. One-sided Fisher exact tests give p = 2.6e-14 for the higher gap share on April 1 and p = 3.0e-11 for the lower late share, but files from one publisher are not independent, so those p-values are, if anything, too small.
• A separate re-run on 2026-10-28 rebuilt the table from the published lead file with the published script and matched it row for row (112 of 112 rows, identical JSON).
• Publication dates are the ones the repository records. A file handed to apps or route planners by other means earlier is not visible to us, and old files removed from the repository are not seen.
• Some gaps are old periods uploaded together much later (40 of all 111 gaps were 100 days or more after their start date). A feed whose next file never came at all appears as a lapse in the census but not in this file-level table.

A test we cannot fudge

To see whether this holds, we recorded three predictions on 2026-10-23 for the files that will start on 2027-04-01, none of which existed when we wrote them:

• G1: between 6% and 18% of new-period files starting on 2027-04-01 leave no valid file on that day.
• G2: that share is higher than for files starting on other days from 2026-10-01 to 2027-03-31 (one-sided Fisher exact test, p < 0.05).
• G3: of the 2027-04-01 files published after their start date, at least 40% leave no valid file on that day.

They will be scored with a fresh census on or after 2027-07-01, and the result will be added to the repository whether they hold or not. The commit dates of the prediction files are the proof that they came first. Separately, 292 of the 574 active feeds (51%) are currently set to expire on 2027-03-31.

What a publisher can do

This is not a judgement of anyone's work: lead times are the publishers', reported as facts, and most of these feeds are kept by small municipal teams. But the mechanism points to two simple protections, each with a trade-off the publisher has to weigh:

1. Publish the April timetable before March 31. Japanese route-search providers ask for roughly two weeks of lead time, and the GTFS Best Practices suggest more.
2. If that is not possible, do not let the current file end exactly on March 31 when the next one is not ready. A valid old timetable for a few days is usually less harmful to a rider than none at all, though it may be wrong where the timetable changed.

The GTFS Data Repository already emails administrators when a feed nears expiry. A March reminder that names the April-1 risk specifically might help more than a general one.

Data and code

Everything is in github.com/munimtechnologies/gtfs-jp-lapses: the census, the lead-time table (leads/2026-10-16/), the April-1 split (gaps/2026-10-16/, made by tools/gap_split.py) and the 2027 predictions (leads/predictions-2027-04-01.md). To reproduce the split: python tools/gap_split.py --leads leads/2026-10-16/leads.csv --start 2023-01-01 --end 2026-06-30 --out out/gaps. Source data: GTFS Data Repository API v2 (gtfs-data.jp); each feed's publisher and licence are listed in the repository. Code Apache-2.0, data CC BY 4.0.

We searched for an earlier count of how far ahead GTFS files are actually published, or of fiscal-year gaps in Japanese feeds, and found guidance on how far ahead to publish and individual expired feeds in aggregator logs, but no systematic count. If you know of one, we would like to read it.

-- MV2, Munim, Inc. ([email protected])