GWR - 3 day seasons under consideration

Possibly a screw-up where the validities for one (rare) ticket type are mistakenly applied to another? I've seen that happen before.

Yes, it's a screw-up, but a worse one than that. The restriction codes that have been defined for these ticket types (NH, NW, NT, NM) already exist for other ticket types. As the restrictions have not been redefined, they are - well, wrong!

It looks as if NH and NM are the same, but for some reason both exist. I've not looked to see if the unpublished restrictions are the same - though obviously they are wrong too.

(I've just cut your quite down to save a bit of space)

I suspect that this all comes down to a problem that was created when P/T seasons came into existence.
There wasn't enough space in the fares database for all the new ticket types that would have been required, so in effect as a ticket TYPE within the fares structure, P/T seasons don't actually exist.
The days of validity are in fact a routeing.

Perhaps this should be sorted before they're rolled out across the board

I find that hard to believe. Based on the 2017 data feeds definitions data, the big files are Flow (100 MB) and "Non derivable fares override" (50 MB). The Flow file has an entry for each flow and each fare, both huge system-wide lists. For flows the size is limited by grouping stations together, to keep the number well below (number of stations)². For fares, each item is kept short - just 2 bytes of header, 6 for flow ID, 3 for ticket code, 8 for fare (in pence), and 2 for restriction code.

I'm not sure what's in the NDFO file - it's said to be any fares the standard processing in the system can't cope with. Since TfL^» 's capping is mentioned, I suspect this file has grown fast and it's probably this one that will break the system at some stage. Note that these special fares still rely on ticket code and restriction definitons.

The ticket code (what we usually call the type - that term is used differently, and inconsistently, in the data feed system) is three characters. You could have 36³ or 24336 of them, and there's nothing like that number now. The codes are defined in the Ticket Types file (told you!) and each is quite long (about 113 bytes). However, the file was still only 130 kB - implying there were only about 1150 codes.

The restriction code is only two characters, giving a maximum of (36)² or 936. That looks quite likely to run out. The Restrictions file was 4 MB, but it's hard to say how much each code uses. The defining data are spread over many items, and it's not clear how many items are typically needed. Worse, multiple time restrictions use a sequence of Time Restriction Date Bands records, with each time restriction kept in another item in this file. However, if the codes were all used, each would have about 4250 bytes. Now, they could be longer (and thus codes not running out), but I suspect not by much.

There is an item type in that Restrictions file called a Ticket Calendar record. The Days field of this has 7 bytes, defined thus:

Quote

A set of 7 markers each set to ‘Y’ or ‘N’, representing the days of the week. The first character represents Monday. If the marker = ‘Y’, then the restriction applies on this day of the week, between the dates in DATE_FROM/DATE_TO. If the marker is ‘N’, then the restriction does not apply on this day of the week, between the dates in DATE_FROM/DATE_TO.

So that's the right place to code these restrictions. However, to invoke this you'd have to generate six extra restriction codes for each existing restriction code used by a season fare, each copying the existing definitions, and adding one of these new ones. I suspect some work is going on to find a way of calling this up more directly. Incidentally, the route is part of a flow definition, calling up an machine-readable definition in the Routes file. There's nothing in that to call up a restriction, so this wasn't an "accidental feature" of the system.

Putting the days of use in as a route has an obvious problem - some season fares already have a route. It will need to be shown as one of six extra season ticket types, but as I said I don't think there is a shortage of such codes. The Description (i.e. name) field for ticket codes is only 15 bytes, so some abbreviation will be needed. But it will add complexity, because extra choices inevitably do. Of course there may be better (and probably a bit Oysterish) ways of getting a similar effect.