31st March 2019 Best Day ever for Train Running?

[whole diary]

[smokey]

Hi I'm back been quite a while since I posted,

However checking up on Realtime Trains today, hundreds of Trains this morning were arriving around 60 minutes early from Penzance to Edinburgh and all points East and West.
Not much good when you find your train had left 60 minutes Early.

I'm fully aware this is because someone somewhere hadn't advanced the clock from GMT to BST, Realtime Trains get their information from Network Rail (and other sources) but won't this little error knock train running results skyward (could it effect Season Tickets refunds? I'm not sure if Sundays count on season ticket refunds for poor running!
Not impressed NR^» (Network Rail - home page)! 

[grahame]

Hi I'm back been quite a while since I posted,

Welcome back!  ... nearly two years!

Wondering if the error is Network Rail's feed ... or Real Time Train's interpretation.   Did you look at Tiger , for example http://iris2.rail.co.uk/tiger/render.asp?file=304759.xml

[bobm]

Good to have you back!

[stuving]

Hi I'm back been quite a while since I posted,

Welcome back!  ... nearly two years!

Wondering if the error is Network Rail's feed ... or Real Time Train's interpretation.   Did you look at Tiger , for example http://iris2.rail.co.uk/tiger/render.asp?file=304759.xml

I see one train that had a dwell at Wokingham from 10:18¹/₂ to 11:19 ... so it looks  more like a source error. If it's a switch in RTT^» (Real Time Trains - website) it would more likely be retrocative when corrected, I think. On the other hand, OTT^▸ (Open Train Times website) has it correct from earlier - but then a fancier correction facility could do that. So that's a definite maybe, then.

[stuving]

This is from a page of helpful info on the TRUST^▸ (Train Running System TOPS) data put out on the Train Movements data feed:

All timestamp values are in milliseconds since the UNIX epoch. But it appears that in certain fields this is incorrect during British Summer Time (UK^▸ (United Kingdom) DST) and is actually one hour in the future. You will need to subtract one hour in order for the times to be valid. This is known to affect the following fields:

    gbtt_timestamp
    planned_timestamp
    actual_timestamp
    canx_timestamp
    dep_timestamp
    orig_loc_timestamp

These are timestamps within the data, about trains, rather than for messaging process. At least I think so, though the choice of time format is a bit odd in that case!

So it looks as if there has to be "BST fudge" flag set in RTT^» (Real Time Trains - website), to correct incoming times, and it wasn't set until about 11:19. (That's 11:19 BST.)

[bradshaw]

Via Twitter by Tom Cairns

“I'm aware of the glitch on @realtimetrains. Unfortunately the code to handle the date changes appears to have stopped working for the first time overnight and it's not something that I've told it to monitor before”

https://twitter.com/swlines/status/1112296489114652672?s=21

The Twitter feed explains what happened

[TaplowGreen]

.......bit early for April Fools day......can't be serious......can it?

[stuving]

There's quite a lot that can be deduced from that Data Feeds information (above) - but time offsets are always confusing, so it helps to check it step by step.

1. The words say that times are given in a standard Unix format, so once scaled and shifted so zero is at 00:00 (GMT) today they are in GMT. Or, put that another way, in order to shift them so zero is at 00:00 BLT* today you need to know whether to do it for GMT or BST. So times as supplied are unconverted GMT.

2. But not for the timestamps listed, one of which is the one you need in TRUST^▸ (Train Running System TOPS) data in most cases (actual_timestamp). Those have an hour added to therm, i.e. when processed as intended for timestamps in GMT they end up in BST.

3. I seem to remember that RTT^» (Real Time Trains - website) only uses TRUST data if if doesn't have better data available (from the Train Describer feed, I think).

4. What we see in an early train such as this one (2P11 0620 RDG^‡(resolve)-PAD^» (Paddington (London) - next trains)) is actual times an hour before scheduled ones, which are the true times as it ran near enough to time. So it left Southall at 07:02 BST, 06:02 GMT, and was shown at 06:02. That must be a GMT value that hasn't been converted.

5. For most trains there are some times (even well before RTT was fixed) that show the right hour. In the example, its actual arrival at Langley is 06:46, vs WTT^▸ (Working Time-Table) 06:48. That looks like one of those TRUST timestamps which is in BST though it shouldn't be. If one of those was converted but not fudged to correct the error, it would display as 07:48 - an hour late.

6. Since the fudge factor is to subtract an hour, if applied to data without the error it would cancel the conversion to BST, which is what we see. But it is hard to see how it could happen, for any plausible way of implementing it so as to affect just those five named values.

So given what we do see, my earlier suggestion was wrong - it was the standard BST conversion that was missing until fixed at 11:19.

* British Legal Time, for want of a better single name to be valid all year. For some reason we don't have a name for the time we actually use, which is either GMT or BST as appropriate. Most other time zones' names do apply all year. The problem they have is that Summertime or Daylight Saving doesn't have a counterpart for the winter period.

[CyclingSid]

NATO time zones are not going to be comprehensible to most people; but we went from Zulu on Saturday to Alpha on Sunday. BST is generically known as Daylight Saving Time. GMT is really a hangover from the Empire, officially it is now UTC.

At least we don't have Double Summer Time, possibly died with the end of WWII^▸ (World War 2 - 1939 to 1945)

[stuving]

NATO time zones are not going to be comprehensible to most people; but we went from Zulu on Saturday to Alpha on Sunday. BST is generically known as Daylight Saving Time. GMT is really a hangover from the Empire, officially it is now UTC.

There's no shortage of labels for all-year fixed offsets from UTC - that's not the tricky bit. But I was wrong to say there is no name for out timezone - the one we share with Ireland and Portugal - it's WET (Western European Time). It's just that noone uses it; still less do they use its seasonal flavours of WEST and WEWT.

Partly that's because we think "winter time" is just normal time with no extra hour, so needs no extra label. The first part is true, but the second isn't as soon as you want to talk clearly about what the time is in winter. The people who make lists of these things and put them on the web say that CET^▸ (Controlled Emission Toilet) (for example) is the winter one only, and it's CEST in the summer. I reckon if you need to set up an event (say a conference call) across Europe, "9:00 CET" will be understood as clock time in Germany winter and summer.

Those lists also show the American usage, e.g. Eastern Time which flips between Eastern Standard Time and Eastern Daylight Time. That is pretty logical, provided us outsiders add "US" in front of it, though the different meaning of the inserted "S" is a bit annoying.

And all that confusion exists before even thinking about making changes ...