Skip to main content

The transition to and from British Summer Time makes life a bit awkward in some scenarios, like travel times and energy calculations. Because the UK energy industry operates on UTC (Coordinated Universal Time, the current official name for Greenwich Mean Time) all year round, there are several pitfalls to be aware of when working out our energy usage and bills when suddenly a 23-hour day comes along. Here are some of them:

  1. Time of Use electricity tariffs
    Some customers will be on plans with different unit rates for different times of day. The simple example of this is Economy 7, which in much of the country charges a lower rate from midnight to 7AM. These timings change from region to region, but it's usual for them to be UTC times. This means that the cheap rate runs from 01:00 to 08:00 BST. Most modern equipment, including smart meters, will allow for this. Things that don't (clockwork timers on immersion heaters, for example) will have to be adjusted twice a year if they're to be sure of only operating at cheap rate.
      
  2. Smart meter readings are I think always taken at midnight UTC, so during BST this means 01:00AM.
      
  3. OVO's Usage charts reflect the change, but their presentation of the results on the Day page is fudged to make the figures fit. Numbers are shown for each half-hour from midnight to midnight BST, but the underlying data are for the period from midnight to midnight UTC. To 'correct' for this, the data for the first hour on the page - labelled 12:00am and 12:30am - in fact belong at the bottom of the table and to the following day. The figures that ought to be shown for 12:00am and 12:30am belong to the previous day.
      
    This won't normally have much significance, because usage at that time of night doesn't vary much from day to day for ordinary people, and it's usually a lot less than during daytime anyway. It will matter, though, on occasion, as some customers have discovered and asked about in these forums. A couple of examples:
      
    -   A tenant arrived one evening at his flat that had been empty for some weeks. He was alarmed to discover when checking the electricity account later that there had apparently been a lot of usage in the middle of the night before he arrived. There hadn't, but the heating he turned on when he arrived was still on after midnight, and the electricity it used between midnight and 01:00 was displayed as if it had been used 24 hours previously.
      
    -   An EV user set his car to charge at midnight one day, then later checked his usage charts to see how much he'd used. He was surprised to note a spike in his chart at midnight the previous day, when there had not been any major energy-consuming equipment in operation.
      
    OVO are aware of this problem, but have clearly chosen not to do anything about it.
      
  4. Those attempting the Power Move challenge should be wary of the change. I'm not sure whether the weekday consumption is measured from midnight BST or UTC, even though the peak timings are obviously BST. Again, this won't make much difference for ordinary users, but for those of us who like to get precise results, it could make the difference between earning and not earning the reward if we're on the borderline.
      
  5. Most of those who retrieve smart meter data with 3-figure precision will know that they have to take care when manipulating the data, to be sure that the numbers are in the right time slot. It can be quite confusing and I'm sure we've all got it wrong at some stage. Clock-change day itself is particularly challenging.
      
  6. OVO’s system retrieves the current time zone from the device operating system. If this isn’t set properly (e.g. to UTC + 00:00 with daylight savings time applied automatically), then the usage pages won’t necessarily show the correct local timings.
    oThanks to @deanphillips2005 for leading me to this revelation 😊]  
      

There may be other consequences of summertime that I can't think of just now, but please point out any omissions, additions or corrections in a reply here.

 

@Firedog you and I had quite a discussion on this six months ago and I think you have summarised the conclusions very well. Doesn't time fly!


Aha! It was you with the EV charging on the wrong night! I should have checked, sorry!


The point that we had got to with that discussion was that I had checked the billing against usage and found it to be correct within a fraction of one percent so it appears to be a presentation issue. However, should that displacement cause an issue with the timings associated with CA then that could be more of an issue with customers if they have a billing discrepancy during BST and they know about the way the HH readings are presented. Any thoughts?


This whole business is spectacularly confusing unless you happen to have a 25-year-old brain firing on all cylinders. Billing will of course be accurate, because that depends solely on meter readings. Readings during BST are taken at 01:00, so by totting up the 48 numbers shown, you actually get the right amount to match the difference in meter readings.

The problem is purely presentational, so someone who isn’t aware of the fact that the first two bars on the Day chart should in fact be at the other end of it could get a nasty surprise - as you did last year.

I suspect that Charge Anytime also works (behind the scenes, at any rate) on UTC all year round. I’ve a feeling that any attempt to adjust for BST would be fraught with difficulty. Anyone on a Time of Use tariff (e.g. Economy 7) will surely be aware that the cheap rate normally starts an hour later during BST. 

We haven’t seen many complaints about this bizarre behaviour, so we can hope that not many people both notice the anomaly and bother about it if they do.

 


I agree. It's only because we decided to mess around with what we call a day do the problems arise. There are still 24 hours in one rotation of the Earth and it is only us that makes it confusing. I rest my case with what I have as a signature. It all went downhill after we  invented the wheel (sigh)


Although it doesn’t affect OVO customers, general ToU tariffs also have a problem especially when they are priced per half hour. It can be extremely confusing to match the price to the specific half hour. 
On the clock change event, we are not the only country to do this so I wonder how they cope elsewhere


The EU voted to stop daylight saving in 2018 but sort of not got round to actually doing it. The reason for DST was apparently to save energy but the link says studies show that it doesn’t.

https://www.euronews.com/green/2024/03/29/do-clock-changes-save-energy-experts-say-the-difference-is-negligible

 

When I worked on the railway we had equipment synchronised to MSF (Rugby) and DCF (Germany) as a backup. This was fine until we got to March/October and there was a week difference between the change over dates but not a problem unless MSF was down for maintenance (often - until they moved it from Rugby to Cumbria) and the system then synchronised to DCF but only corrected for a one hour difference when it could have been either two hours or even zero. Undoing the damage done to the log files was a nightmare when producing evidence for incidents on the railway.

 

 


[ot]

You had me Googling again. Wikipedia tells me that “The Rugby transmitter's callsign was MSF, where 'M' is one of the ITU prefixes allocated to the United Kingdom, and the letters 'SF' were allocated for no documented reason.


Thanks @Firedog for the explanation of the OVO usage data for the GMT->BST shift.

How about the switch back from BST to GMT (on 27 Oct in 2024) ...

I’ve just been looking at the half-hour usage data displayed by OVO for my account for 27/10/2024 (when 02:00BST shifted to 01:00GMT at 02:00BST), using Chrome on a Windows 11 PC.

My usage data shown by OVO for the 27th only has 46 “proper” entries (a 23 hour day that should appear as a 25 hour day?):

  • The first two entries 12:00am and 12:30am have a usage figure of “-”.
  • Then 1:00am and 1:30am appearing twice as might be expected - the first possibly meaning 1am BST, and the second 1am GMT?). However, the first 1.00am and 1:30 slots actually showthe consumption values that should show in the 12:00am and 12:20am slots. The second pair show the correct consumption values for GMT times.
  • There are no entries shown at all for 11:00pm and 11:30pm. 

I can see consumption values for the 11:00pm and 11:30pm slots when I download the JSON as described above. So they appear to be missing altogether from the day usage page displayed for my account.

Rather confusing!


Rather confusing!
  

That sums it up well.

I’m inclined to think that since the great majority of customers (a) don’t use much electricity around midnight, and (b) the little they do use doesn’t change much from day to day, it’s not worth the coding effort needed to make cosmetic changes to web pages that are only there for guidance.

Yes, consumption between 23:00 and midnight on 27 October is missing altogether from the Day usage tab. You’ll notice this in the total at the top of the page, too: it’s different from the corresponding figure on the Month tab. I suppose the reaction is So what? 

Since you’re clearly comfortable with the JSON data that are readily available, I can only suggest that you ignore the weird BST artefacts on the Usage pages. 


I may have said this elsewhere (but can’t remember) .. ‘others’ nudge the extra 2 hh slots during BST into the next day so (during BST dates) I see an hours usage immediately visible on a days usage from the early hours - then obviously it falls back into line during GMT dates


Just to note that usage “around midnight” matters to Economy 7 users (like me), and I’m trying to check things against my bills.  

Is it possible to get a copy of your Excel macro that you mentioned in another post, to convert JSON data?


As we said at the meeting yesterday it would be useful if the data could be downloaded in XLS format like you can with Octopus. Apparently it is one of those things that can be done but doesn't seem to have enough priority to actually get done. Does anyone have any levers for this?


Is it possible to get a copy of your Excel macro that you mentioned in another post, to convert JSON data?
 

Oh dear, it’s a very seat-of-the-pants thing that I’m not sure will be much use to anyone else. I’ll see if I can work out a way of sharing it. Wait out!


Eh? I just use CyberChef :P

https://gchq.github.io/CyberChef/#recipe=CSV_to_JSON(',','%5C%5Cr%5C%5Cn','Array%20of%20dictionaries') for CSV to JSON

https://gchq.github.io/CyberChef/#recipe=JSON_to_CSV(',','%5C%5Cr%5C%5Cn') for JSON to CSV

If needed, use the search tool to find CSV to JSON or JSON to CSV and drag it into the Recipe manually.

Just feed it the file either as raw input or the upload tool, hit Bake (or be lazy and use Auto Bake like I do) and walla!

Good thing GCHQ has some stuff that isn’t sekrit! XD


Don’t worry about the macro @Firedog thanks. The other conversion sites will probably do the trick. Also there is http://www.convertcsv.com/json-to-csv.htm

 


Reply