Missing data early Sunday morning

I see a gap in my data from early this-morning. Was this expected?

Sunday 25th October

Related to the end of BST?

Yes I have missing data too.... I assume it's the clock change from BST to GMT at around 2am....

The yellow on my graph is upside down for 1 hour

https://www.thinkbroadband.com/broadband/monitoring/...

Thinking about it there was an extra hour last night - so I would n't expect to see missing data, I'd expect to see an extra hour of data in the day. Looking closely at the times along the bottom that are usually every 2 hours there appears to be only a one hour gap from 12am-1am, which might account for a 'missing' hour. But I believe the rendering is wrong; or I'm not understanding what is being rendered.

In reply to a post by rmay_uk:

I see a gap in my data from early this-morning. Was this expected?

Sunday 25th October

Already on it.
No.. I specifically asked that we had made sure daylight saving time is properly handled but it messed that up
We still have the data on the firebricks so trying to see if we can recover it.

It's probably an error in how we push the data to Clickhouse. On my data I see:
2026-10-25T00:58:20+01:00
2026-10-25T01:00:00+00:00

It should be
2026-10-25T01:58:20+01:00 .. first 1-2am (BST) and trigger an hour later
2026-10-25T01:00:00+00:00 .. second 1-2am (GMT) period

seb

Graphs should be fixed for missing data from the morning.

You *may* not see first or last hour of the day on historicals. We're re-building the graphing soon so if that breaks I'd rather wait and deal with it then as the way we draw graphs will change completely and this is a real pain right now.

CSV download has a bug on the timezone which will be fixed tomorrow where the timezone switch appears to have been an hour early, but the data is all there. XML is all in UTC so should be fine.


seb

hmm. graphing should be continuous because time and data are continuous over clock changes. What should be discontinuous is the labelling of the x [time] axis.

In reply to a post by DFScale:

hmm. graphing should be continuous because time and data are continuous over clock changes. What should be discontinuous is the labelling of the x [time] axis.

It was a bug drawing the graph.

The CSV download still goes 0059(BST/+0100) -> 0100(GMT/+0000).. this should happen 0159GMT though. If you look you will see 0159-->0100 though so it's a mis-classification of the time zone.

What I was saying was that you may find that after the end of today, if you view today's graph, it will finish at 23:00, as it's a fixed 24-hour graph, if I remember correctly. We're going to fix that when we redo this interface completely, hopefully in the next few weeks. The XML data is there, and the CSV will be fixed tomorrow anyway, so you won't lose any data.

seb

In reply to a post by seb:

What I was saying was that you may find that after the end of today, if you view today's graph, it will finish at 23:00, as it's a fixed 24-hour graph,

If you do the graphs 0100 to 0100 GMT for wintertime and 0200 to 0200 BST for summertime, you can brush the change of clocks under the carpet and just label the x axis GMT or BST as appropriate. All the discontinuities will be between graphs rather than on any one of them.

In reply to a post by DFScale:

If you do the graphs 0100 to 0100 GMT for wintertime and 0200 to 0200 BST for summertime, you can brush the change of clocks under the carpet and just label the x axis GMT or BST as appropriate. All the discontinuities will be between graphs rather than on any one of them.

The new system is going to completely re-draw them and planning some interactivity, etc so this will become less of an issue. The code we have doing this is very old and not great.

seb

ok I think historical for 25th is fine.. 12am to midnight

Looks good to me too - thanks for the super quick turn around.