Been tidying up some of the latest TfL road closure MPs, and noticed a discrepancy in the times shown in WME vs on the TfL website for the same closure.
The closures in question run from October 23rd through to November 6th, i.e. spanning the BST-GMT changeover. The MP details in WME then list the closures as running from 2100-0500 each night, whereas the TfL site lists them as running from 2200-0600… So which is correct?
From experience here in Manchester, overnight closures tend to be 2100-0500
I’ve now pulled the corresponding closure feed data from TfL, which rather nicely not only lists the overarching closure period, but also breaks it down into each of the individual overnight closures, and I think I’ve just answered my own question…
In these individual nightly closure data entries, all of the ones up to the October 28th list the closure period as 2100Z-0500Z (Zulu time aka GMT), all of the ones from October 30th onwards list the period as 2200Z-0600Z, and the one on the night of the BST-GMT changeover lists it as 2100Z-0600Z.
Or to put it another way, the closure always starts at 2200 local time each night, and always finishes at 0600 local time the next morning, which corresponds to the closure summary description on the TfL site.
Looking at a different TfL MP pin related to a closure which takes place entirely within BST, I see that it too is showing the start and finish times as 2100-0500, whereas the corresponding raw data from TfL lists the times as 2100Z-0500Z (again, 2200-0600 local).
The underlying W.problems data for this MP then has startTime and endTime timestamps which correspond to 2000Z-0400Z :shock:
So it looks as if Waze have received the raw data from TfL, noted that the start and finish times are listed as 2100-0500 without also paying attention to them being in Zulu time, noted also that the dates are within the BST period, and then applied their own unnecessary BST-GMT correction to the already-GMT times. When WME then displays the MP data, it then applies a GMT-BST correction again to give the 2100-0500 result shown in the MP dialogue. WME itself isn’t therefore doing anything wrong - it doesn’t know that the timestamp data provided by the server is out by an hour - but the resultant data displayed within WME is wrong, which has consequences for any closures set up based on what WME shows…