I think you actually play similar to my playing style, but ...
However, if timetable period is fixed, you need define it either using tick or more convenient hh:mm, not days/months,
because days/months would be shifted to another date at the end of period.
... I think you missed some features of my patch...
My timetables have an offset (Days, Months) and a length (Days, Months). The offset is vehicle-specific, the length is timetable-specific.
IMHO what you want is both offset and length in Months.
Then you have e.g. a timetable of length 4 months. For simplicity, assume a vehicle with offset zero months. It contains orders e.g.
Arrive 27th January, Depart 3rd February
Arrive 12th February, Depart 16th February
Arrive 27th February, Depart 11th March
Once the vehicle has completed its round, the timetable will shift to:
Arrive 27th May, Depart 3rd June
Arrive 12th June, Depart 16th June
Arrive 27th June, Depart 11th July
No days are shifted. But you obviously have to cope with the fact that different months have different lengths, i.e. sometimes the period between 27th and 3rd has 7 days, sometimes just 4, 5 or 6 days.
But, based on former discussions, I can just say: The latter problem can be solved by a 24h patch, just unfortunately, there is none in trunk yet, thus when timetabling one has to work with the infrastructure already present.
And if I look at the length of my patch queue, introducing 24h in the same patch queue would just be ways too much code in one queue...
(if I did not understand your problem correctly, please correct me...)
wrt daylength: daylength patches have the problem that they tag into so many core game features that nobody has yet found a way that would be acceptable for trunk inclusion. and additionally they have many problems where people can't agree on what they should do or shouldn't do.
I know why I asked for details...
1) all GUI stuff should apply the daylength scaling (as in converting ticks to days). this shouldn't be a big problem, but it potentially involves touching a lot of places in the GUI code.
Probably, a daylength part has to replace DAY_TICKS by a variable / inline function returning that variable. Thus, this part shouldn´t be too complicate indeed.
2) rounding to full days becomes too crude for useful timetabling, so there needs to be a way to specify fractional days (this is where the concept of an independent 24h clock comes in handy)
Yes. This would be a bigger problem, where I agree that you actually would need something like 24h support.
Anyway, I personally circumvent the problem of day length by periodically applying the Date Cheat. Works without problems in my experience.
(as a cheap variant of a day length patch, one might even think about a config variable "Keep game in Year X", with the effect that once the 31st December is reached, game restarts with the 1st January of the same year. Such a patch should be quite trivial, as it would just have to do what I currently do manually by applying the Date cheat).