Skip to main content
Firedog
Super User
Super User
April 4, 2024

Summertime - and the livin's not easy

  • April 4, 2024
  • 19 replies
  • 503 views

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.
    [Thanks 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.

 

19 replies

BPLightlog
Super User
Super User
October 31, 2024

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

Bring me Sunshine ~ E&E {Solar PV, Battery Storage, Hybrid EV, ASHP and Home Assistant automation}
October 31, 2024

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?

Peter E
Super User
Super User
October 31, 2024

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?

Reducing my yearly fossil fuel usage with an EV (-900 litres petrol), A2AHP (-8,700 kWh gas) and Timed Immersion heater (-1,500 kWh gas)
Firedog
Super User
FiredogSuper UserAuthor
Super User
October 31, 2024

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!

Noel | I have no official status; I'm just a volunteer who comes here to help other customers. My gear: Aclara SGM 1416-B Electricity-only E7 meter; Chameleon IHD3-PPMID-AAA | It may look as if I know what I’m talking about, but don’t let that fool you. |
Blastoise186
Super User
Super User
October 31, 2024

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

Securing energy by zapping security bugs... For that is The Blastoise Way! Remember, I'm just like you - AI Powered Evil Geniuses aren't Staff!
October 31, 2024

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

 

Firedog
Super User
FiredogSuper UserAuthor
Super User
April 5, 2025


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.
  

I think this may have been fixed, at last. On a couple of days in week 14 (31 March - 6 April 2025), I noticed a Day usage chart for the latest day with just the first two entries of 48 showing, both bars and figures. So the page seems to be pre-populated with the last two Hh figures from the previous day, i.e. 23:00-00:00 GMT = 00:00-01:00 BST. 

These ghosts quickly disappeared, though, and I haven’t seen them since, so it seems to be working as it should. Many thanks to whoever made this fix 🙇‍♂️   

Noel | I have no official status; I'm just a volunteer who comes here to help other customers. My gear: Aclara SGM 1416-B Electricity-only E7 meter; Chameleon IHD3-PPMID-AAA | It may look as if I know what I’m talking about, but don’t let that fool you. |
Firedog
Super User
FiredogSuper UserAuthor
Super User
April 5, 2025

For anyone who downloads their own usage data for homespun analysis, the UTC-BST dilemma has those making data available each solving the problem in their own way. I checked a few different sources of my own data to see how the numbers delivered by my meter were presented. This was the result:
  

Click on the image for a more legible version


I aligned the columns so that the Hh consumption was the same for all five variations. For the first four data sets, I am able to specify a single day; this results in four sets of 48 usage figures, with two of them starting an hour later than the other two. The Bright CSV contains all the data from time immemorial, so I grabbed the ones dated 4 April. Bright is the only set that helpfully specifies the time zone (the ‘Z’ at the end of the time stamp signifies UTC). Both of the websites (OVO and Bright) choose to display BST timings.

The real outlier is n3rgy, which is the only one actually to do it properly! The meter can’t know how much energy has passed through it during a particular period until the end of that period, so the count from zero at midnight to half-past is finalized at 00:30, so that’s the time stamp the meter applies. 

The bottom line is that spreadsheet jockeys have to be very careful to put each bucket into the right time slot.
 

Noel | I have no official status; I'm just a volunteer who comes here to help other customers. My gear: Aclara SGM 1416-B Electricity-only E7 meter; Chameleon IHD3-PPMID-AAA | It may look as if I know what I’m talking about, but don’t let that fool you. |
MikeWilliams
Newcomer
Newcomer
October 13, 2025

Following changes made by OVO to their login process I have fixed my app which saves “your” OVO Usage Data to a SQLite database.

Full source code at https://github.com/MikeWilliams-UK/My-Ovo-Data

During getting this working ​@Firedog pointed out that the data I was pulling from the API was all in local date times (i.e. BST)

In another thread we established that I was calling the “old” API endpoint

https://smartpaymapi.ovoenergy.com/usage/api/half-hourly/{{accountNo}}?date=2025-10-01

which always retrieves local date time stamps.

We determined that there is another endpoint which is used by the OVO web page
https://smartpaymapi.ovoenergy.com/usage/api/half-hourly-local/{{accountNo}}?date=2025-10-01

Which despite it’s name half-hourly-local retrieves the timestamps as UTC

Does anyone know if there is an endpoint called half-hourly-utc as this is what the half-hourly-local endpoint should have been named