Network Pulse

← All notes

How a school-day journey is marked, and how one operator's stopped working

Status: measured. Andrews of Tideswell's published dataset read live from BODS on 2026-09-09, against the GTFS export loaded here the same day.

Somebody suggested Andrews of Tideswell don't distinguish school days from holidays. They do — carefully, and in the right place. What has happened is narrower and more interesting: the school dates they published ran out on 22 July 2026, and nothing has been published for the year that started this month. The instruction survives; the dates it points at have expired.

This note is mostly about where that instruction lives, because it is the part nobody can see from a timetable.

The field that says "school days only"

GTFS — the format most tools read — has no school-day concept at all. Its calendar.txt gives seven weekday flags and a date range, and its calendar_dates.txt adds or removes individual dates. A term-time service is spelled out date by date, or not at all.

TransXChange, which is what operators actually publish to BODS, does have the concept. It has two parts, in different places in the file.

A named organisation with its term dates, declared once per file:

<ServicedOrganisation>
  <OrganisationCode>LMS</OrganisationCode>
  <Name>Lady Manners School</Name>
  <WorkingDays>
    <DateRange><StartDate>2025-11-04</StartDate><EndDate>2025-12-19</EndDate></DateRange>
    <DateRange><StartDate>2026-01-06</StartDate><EndDate>2026-02-13</EndDate></DateRange>
    <DateRange><StartDate>2026-02-23</StartDate><EndDate>2026-03-27</EndDate></DateRange>
    <DateRange><StartDate>2026-04-13</StartDate><EndDate>2026-05-03</EndDate></DateRange>
    <DateRange><StartDate>2026-05-05</StartDate><EndDate>2026-05-22</EndDate></DateRange>
    <DateRange><StartDate>2026-06-01</StartDate><EndDate>2026-07-22</EndDate></DateRange>
  </WorkingDays>
</ServicedOrganisation>

And a reference to it inside each journey that follows the school calendar. This is journey 326, the 07:00 from Sheffield Interchange to Lady Manners School, exactly as published:

<VehicleJourney>
  <VehicleJourneyCode>326</VehicleJourneyCode>
  <DepartureTime>07:00:00</DepartureTime>
  <OperatingProfile>
    <RegularDayType>
      <DaysOfWeek><Monday /><Tuesday /><Wednesday /><Thursday /><Friday /></DaysOfWeek>
    </RegularDayType>
    <ServicedOrganisationDayType>
      <DaysOfOperation>
        <WorkingDays>
          <ServicedOrganisationRef>LMS</ServicedOrganisationRef>
        </WorkingDays>
      </DaysOfOperation>
    </ServicedOrganisationDayType>
  </OperatingProfile>
</VehicleJourney>

Three parts, and all three carry weight:

  1. DaysOfWeek — Monday to Friday. On its own that means every weekday.
  2. ServicedOrganisationDayType / DaysOfOperation / WorkingDays — narrows it to days the named organisation is working. DaysOfOperation is the "only when" wrapper. Its sibling DaysOfNonOperation means the opposite, "except when", and the two are easy to misread for each other.
  3. ServicedOrganisationRef — points at the block above, which is the only place the actual dates exist.

So the journey says weekdays, but only when Lady Manners School is working.

Which journeys carry it

The marker sits on individual journeys, not on the line. Line 257A has four journeys and two of them are school:

Journey Departs Days School-day only
325 07:00 Saturday no
326 07:00 Mon–Fri yes — LMS working days
327 15:45 Mon–Fri yes — LMS working days
328 15:55 Saturday no

Line 173 has fifteen, of which three are school:

Journey Departs Days School-day only
334 07:15 Mon–Fri yes — LMS working days
342 08:15 Mon–Fri yes — LMS working days
341 15:45 Mon–Fri yes — LMS working days
329, 330, 331, 332, 333, 343 07:50–17:50 Mon–Sat no
335, 336, 337, 338, 339, 340 08:15–16:50 Mon–Sat no

Journeys 342 and 335 both depart at 08:15, Monday to Friday. One is the school journey and one is the everyday one — the extra bus laid on in term time, which is exactly the pattern the field exists to express.

They go further than the minimum. A second 07:00 journey on 257A runs Saturdays plus an explicit list of date ranges — 20–24 Dec, 27–31 Dec, 2–5 Jan, 14–22 Feb, 28 Mar–2 Apr, 7–12 Apr, 23–31 May. Those are precisely the gaps between the term ranges above. Term dates and holiday dates, written out separately and interlocking exactly.

What expired

Academic year First date covered Last date covered Weekdays covered
2025-26 04 Nov 2025 22 Jul 2026 181
2026-27 — — 0 of 234

The dataset itself says why:

dataset   20800  Andrews Coaches_20800_20251120 05:46:00
status    published
created   2025-11-12
modified  2025-11-20
lines     172, 173, 178, 257, 257A, 257B

That is the live record, read from the BODS API on 9 September 2026. It is the only dataset published for ANTR, and it has been unchanged for nearly ten months. Not a stale copy at our end — the published copy.

Why nothing flagged it

The same file produces journeys that look current and journeys that vanish, which is what made this quiet.

An ordinary Monday-to-Friday journey has no dates to expire, so the conversion to GTFS gives it a fresh window — services 214, 216 and 383 here run 5 Sep 2026 to 5 Jun 2027. A school journey carries explicit dates, those dates have run out, and it resolves to no operating days at all.

In our GTFS the five school journeys land in service 384, which has no calendar.txt row at all and a single added date, 26 March 2027. Two further things about that are worth knowing before anyone reads meaning into it:

  • A GTFS service with no calendar row is legal. calendar.txt is optional when calendar_dates.txt defines everything. 459 services in the current export have no calendar row.
  • Service ids are feed-wide, not per operator. Service 384 is shared by Bee Network's lines 135, 17 and 100 — 28 trips against Andrews' 2. The converter numbers services across the whole feed and pools every journey with identical operating days into one, so 384 is not "Andrews' calendar". It is the bucket for anything that works out to "26 March 2027 only".

This is one operator, not the industry

Term dates are being maintained by most operators around here. Their school services carry the holidays as removed dates, all of them inside the current academic year:

Operator School calendar covers Removed days
Stagecoach East Midlands 05 Sep 2026 → 05 Jun 2027 265–274 across six services
Team Pennine 07 Sep 2026 → 31 May 2027 167
Globe Coaches 07 Sep 2026 → 31 May 2027 166
High Peak 2026-27 166
Andrews of Tideswell ended 22 Jul 2026 9, all bank holidays

Nine removals against a hundred and sixty-six is the signature. Andrews' nine are Christmas week, New Year's Day, Good Friday, Easter Monday and the two May bank holidays — the ordinary service's bank holidays, and nothing about schools at all, because the school instruction no longer resolves to any date.

What follows

Who has to fix it is not yet settled. The fix itself is small -- republish dataset 20800 with Lady Manners School's 2026-27 term dates, since the structure in the file is already correct and only the dates are missing. But SYMCA prepares and supplies TransXChange to TNDS on behalf of several smaller operators, Andrews among them, so this file may not have been authored by the operator at all. Nothing in it says who produced it: schema 2.4, revision 8, and a machine-generated filename, with no producing system named. Until that is established the finding is about the file, not about the operator, and this note names no one as responsible. Being wrong about that in front of a supplier would cost more than the fault is worth.

The consequences until then are not. Five journeys across two lines cannot be planned, journey-planned or measured, because in the published data they do not run. Any "did it run" figure covering them will report nothing scheduled, and any passenger looking them up will be told there is no bus.

And there is a gap in our own reporting. An operator whose timetable was last published ten months ago will score oddly on delivery and lost mileage, and we have nothing that says so. The dataset's modified date comes back on every fetch, so a "timetable last published" column against each operator would have surfaced this without anybody asking the question.