What’s the time?

According to the computer I’m writing on, right now it’s 15.52.

According to my phone it’s 15.52.

According to my laptop it’s 15.52.

According to the energy industry it’s 14.52.

The Swedish electricity industry decided that instead of following the very important Law 3 they would, of course, go their own way and store all time in their systems in GMT+1.

Law #3: Store it in UTC

This one is really more of a systems design law in general. I’ve lost count of how many times I have seen systems built with the timezone of the original company headquarters. Inevitably, unless you are quite disciplined, users will end up seeing their dates in your companies’ timezone. This is pretty annoying, especially if they are located on the other side of the globe.

Source: The 5 Laws of API dates and times

The issue is that all values are stored in GMT+1, not even in the local time of the facility. That means that during summer all times are off by 1 hour. If we displayed an electricity consumption chart for your office and your lunch break was between 12.00 and 13.00 the chart would be an hour wrong. It would always look like your lunch break started at 13.00. Which, if you were a company trying to save money on its consumption might be quite confusing. You can imagine the poor lonely employee who always eats his lunch later than everyone else getting blamed for using the microwave too much!!

What are Energimolnet doing to help?!

1.0

In the first version of our API (1.0) we had tried to conform to the rest of the world and use unix timestamps (UTC) when requesting a date and time. For instance you could request from 1366149600 to 1366236000 to request data for the 24 hours of the 17th of April and that is what you would receive. But our system had to do some very strange things in the background. For instance when we received data for 1 energy company day we would need to place that over 2 normal person days in our system. (Because they were sending 1am to 1am)

That was just the tip of the iceberg in terms of the complexities it introduced. It turns out it is very complex to turn non-UTC time into UTC time!

1.1

Our second attempt recognised that how we’d like our API to work, what seems logical, isn’t as important as understanding the industry we are a part of. But we also realised that making or API users work with millisecond resolution timestamps was a little ridiculous when our data was only ever 1 hour resolution and the most common call to the API was for a single day’s worth of values.

We think we’ve created a much simpler solution and that is that requests just ask for a date (no time) and we return all of the values that make up that time. For instance, a request for 201304 will return the 30 days of April, a request for 20130417 will return the 24 hours of the 16th of April. Easy to read, easy to debug, easy to understand!

However, there’s a trick! During summer we return the 24 hours that the grid company has sent us. And that means that we return from 01.00 to 01.00 local time and not 00.00 to 00.00. Of course, in winter we return 00.00 to 00.00. The reason is because if we returned 00.00 to 00.00 during the summer then the sum between the total for the day in our data and the total that the customer would see on their bill would be different, and the last thing we want is angry customers ringing their electricity companies up to complain about them being overcharged compared to what the Energimolnet service says or complaining to us that our numbers don’t add up.

TL;DR

Times aren’t stored logically within the energy industry. Ideally everything would be in UTC but it isn’t. Subsequently, we’ve moved away from UTC too. Rules were meant to be broken.