Some smart meters aren’t so smart about Daylight Saving Time


It seems — and is — a geeky thing to write about, but Daylight Saving Time can cause serious problems for some smart meters and meter data management systems.

I know this from 30 years of experience…

Problem 1: Hourly data recorded by smart meters. Conventional electromechanical meters don’t do this; they’re more like an odometer that merely advances continuously. But smart meter systems record usage every hour and mark it with the time the energy was used.

Older time-of-use (TOU) meters — an early “smart-ish” meter technology — do record hourly data. However, they aren’t easy to reprogram. Millions of TOU meters are currently in use.

Therefore, smart meters must deal with that pesky extra hour each autumn. When clocks are set back, there are 25 hours on the first day of standard time. Also, each spring there’s a “hole” when clocks are moved ahead one hour.

Problem 2: Governments have a nasty habit of not cooperating. As the map above shows, nations — and even states or provinces within a nation — have different DST policies.

Many utilities have service territories that cross “DST borders.” Their systems must account for meters in the DST area that gained or lost an hour — or is it for the ones that didn’t? And this happens twice a year.

Problem 3: DST is a moving target. DST rules are subject to change. For example, the U.S. Energy Policy Act of 2005 changed the dates of the time changes: it pushed the fall switch one week back, and the spring change one week forward.

Many countries followed the U.S. lead on this, but Europe has not. So for one week each fall (starting yesterday) and one week each spring, the normal time differential between Europe and much of the rest of the world is one hour different from the rest of the year.

Keep this in mind if you’re calling someone in Europe this week.

So what? These problems often cause TOU and smart meters to report incorrect data. Sometimes data is assigned to the incorrect hour. Other times, all of the data gets time-shifted in the wrong direction — or not time-shifted when it should be. Such problems tends to be worst where the time assignment gets made in custom software, or where reprogramming is more difficult — such as in millions of existing meters in the field.

The result: Billing inaccuracies that can affect large numbers of customers and that require thousands of person-hours of labor to correct.

For example, for some utilities the cost of going out and reprogramming older TOU meters is too high. So every year they simply tell customers that their TOU meters will be off for those two weeks — until the TOU meters are replaced with true smart meters that can properly handle the new DST rules and which can be reprogrammed.

I’ll be reminded by this by my desk phone, which is still programmed with pre-2005 DST dates. Fortunately the clock in my car seems to have switched over properly. Also, my smart thermostat — now run by EnergyHub — is displaying the correct time.

What’s a utility to do? Check your smart meter and meter data management systems, as well as consumer energy data web presentment, for possible DST-related discrepancies. If you find any, correct these problems if you can. But if you can’t fix them, be sure to tell your customers what to expect — promptly and clearly.

I’ll check my own smart meter and online energy data for DST discrepancies when I get home tonight.

This article originally appeared on eMeter’s Smart Grid Watch blog. Chis King is the Chief Regulatory Officer for eMeter. He is a nationally recognized authority on energy regulation and competitive energy markets, and is widely recruited by regulators and legislators to consult on technology issues in electric restructuring and grid management.


Randy Owens

Ahh DST. My favorite time of year! Some utilities have figured it out from a metering perspective and simply leave their meters in standard time year round. This makes things MUCH simpler from a metering perspective, but then you have to rely on the CIS to do the right thing. That’s usually not too hard when you are billing with registers, but toss in some interval billing and step it up a bit to add in MDM-calculated TOU billing and you start to live dangerously when you happen to be the person pressing the SEND button to print the billing run!

Many years ago, I had a chat with Mihran Miranian who at the time was Deputy Director, Time Service Dept, US Naval Observatory. Now THERE’S a job title we can all aspire to! Anyway, Mr. Miranian impressed upon me all sorts of fundamental truths like, “time is an interval, not a value”. All kidding aside, this guy knew more about time than you could ever imagine and I learned a lot while talking to him about all sorts of time related issues concerning meter data collection systems.

The funny thing is, many meters actually work on UTC (which as Mr. Miranian informed me, is used by ‘real machines’) in terms of how they store data internally, but then they have to store other data and offsets to allow them to convert perfectly good UTC to LOCAL time all for the purpose of showing a timestamp on the digital display of the meter. It gets even crazier when you have an MDM that may ask a meter data collection system for a set of data in local time, then the MDC system may have to convert that request to UTC in order to send it to the meter, where the meter promptly returns the data (still in UTC) to the MDC, which then converts it to LOCAL time to send to the MDM, (still with me??) which may then actually convert it BACK to UTC for storage purposes!! It gets better – the next day when the MDM needs to output data to billing, it may very well take that UTC data, convert it to local time, and send it off to a downstream system.

I just sit back, smile, and tell myself that if this was all simple then the utility could hire monkeys to do it. But, I ALWAYS keep that to myself lest I hear someone from the utility respond, “Yea.. I actually already did.”

For extra credit, educate yourself on the difference between UTC and GMT,then go out and impress your friends with the arcane distinction!

Curt J

Report the intervals and register reads all in GST, then apply the offset in reports to local time. Meter programs set to record self reads in local time is just asking for it

Mike Knox

Most Smart Meters can both transmit “interval” data (hourly, 15 minute, 5 minute etc.) AND can be loaded with the rates and tiers and transmit the TOU buckets directly. In the latter case, if DST is not programmed correctly, the intervals could be off, with one hour potentially charged at the wrong TOU rate.

In Ontario, Canada, all Smart Meters transmit hourly data and are in Eastern Standard Time all year round. Some areas of the province don’t observe DST, and a portion of the province is in the Central Time Zone.

All of this is dealt with at the MDM where the TOU tiers are accumulated correctly into TOU “buckets” at the proper “local” time. When DST comes and goes, the extra hour is rolled into the previous hour or the missing hour is spread across two intervals. This works because in the middle of the night, the rate period (Off-Peak) is the same around the point where the clock changes and there is no chance that the extra or missing interval would be charged at the wrong TOU rate.

Comments are closed.