Utility Meter - Different TimeZone on last_reset, next_reset

Configuration
,
1

Hi,
Chasing down an unrelated fault in my system when I noticed that Utility Meters now show UTC for last_reset and the system timezone for the nest reset. They should always use the system timezone for ease of user readability.

Detail form Developer Tools / States

state_class: total_increasing
status: collecting
last_period: 5787.48351655259
last_valid_state: 2899.01698800681
last_reset: 2026-03-03T13:00:00.001447+00:00
next_reset: 2026-03-05T00:00:00+11:00
unit_of_measurement: AUD
device_class: monetary
friendly_name: Standing Load Energy Cost Daily

and the definition:

standing_load_energy_cost_daily:
  name: Standing Load Energy Cost Daily 
  unique_id: standing_load_energy_cost_daily
  source: sensor.standing_load_energy_cost
  cron: 0 0 * * *
  delta_values: false
  net_consumption: false
  periodically_resetting: false
  always_available: true

Would love to see this fixed, and definitely NOT using UTC, but local server time zone. Will do a bug report if necessary, but I have never had any luck with HA bug reports, as I always see features as bugs. Just my rose coloured glasses.

Thanks,
Craig

2

p.s. The reset does happen at the correct time, as 2026-03-03T13:00:00.001447+00:00 is 2026-03-04T00:00:00+11:00

3

I use this for displaying in local timezone (often used with strftime):

{{ state_attr('sensor.daily_irrigation_total', 'last_reset')|as_datetime|as_local }}
4

Thanks,
Not looking to display, just questioning the difference.

5

That seems like a bug to me, but if it is it would be corrected by changing next_reset to report UTC. All other timestamps used in the state machine & recorder database are UTC, and this was changed a few years ago due to the issues caused by using the user’s current localized time in the database. There’s a zero percent chance they’re going back to that.

Edit: not a few years ago, it was 11 years ago: https://www.home-assistant.io/blog/2015/05/09/utc-time-zone-awareness/

6

This is merely a byproduct of Home Assistant capturing, working with, and displaying all past event timestamps in UTC (as it must) and offering the upcoming reset, which will always be midnight 00:00 in local time, using the local timezone parlance (as it should).

Home Assistant runs with local time, and everything happening now or in the future is shown in local time, since this will be of interest and use to the user.

All timestamps of past events, history, are captured and stored in UTC since this is the only way to avoid issues with DST and location.

Since HA does not have a native datetime object, everything is stored as a string, and in ISO format.

state_class: total_increasing
status: collecting
last_period: 170.488681
last_valid_state: 3748.009726
last_reset: 2026-03-01T00:00:00.001843+00:00
next_reset: 2026-04-01T00:00:00+01:00
unit_of_measurement: kWh
device_class: energy

For myself (in the UK) on a monthly reset meter, the last reset was at midnight, and the next upcoming reset is also at midnight. However a DST change occurs at the end of this month, hence the difference in the timezone offset (same timezone, different offset).

If the Utility Meter was changed so that the next_reset was also in UTC, then this would show as '2026-03-31T23:00:00+00:00` which is still midnight, but less obviously so, and would be a problem at the trigger point since HA uses local time not UTC to run - does the reset fire at 23:00 the day before plus one hour, or at midnight? This confuses HA.

If the Utility Meter was changed so that the last_reset was also in local time, then before the DST the last reset would be 2026-03-01T00:00:00.001843+00:00, but at the moment we put the clocks forward, since the next reset is now +1 hour, the past history last reset would have to be updated to add the extra hour to the record to show 2026-03-01T01:00:00.001843+01:00. This makes work for HA.

The fundamental issue (not a bug) much like the Comma of Pythagoras, is that midnight in the past and midnight in the future, where a DST change occurs between them, are not going to be in the same timezone offset. They are not even going to be an even number of 24 hours apart…

7

2 posts were split to a new topic: Problem with my configuration

8

Hi,
I have no issue with the storage of time in UTC. I do have an issue with the display of time in two different formats. As I am a human, and the machine works for me, I would like the machine to translate all UTC into the time-zone I SELECT, and not force me to do the translation.
p.s. @Biscuit Not all resets are at midnight local time. I have a couple that reset earlier (22:00) as that suits the purpose for capturing the energy used at the rate change at 22:00. As you live in the UK, this is NOT an issue for you.

9

The “states” tab in developer tools is a way to inspect what is in the state machine of HA. Its sole purpose is to show you what is in the state machine without translation. Using your words, it’s for people who want to know what the machine is doing.

If you want something “easy to read” then the dashboard is for you. There’s a number of cards that can show you the translated time that you desire. The dashboard is where you can make the machine work for you.

10

Hi,
As a programmer, I completely agree. Time ZONES are the bane of life.
As a user, I want to see time in my format, as that is a programmer issue.

The states tab is a display dashboard, and therefore the display should show the times all in the same format as chosen by the user.

All of this is offered as criticism to improve HA, and make it more user friendly.

11

The states table is to see the under the hood values, not the translated states. That’s why it’s in settings → developer tools, not a main dashboard. You can view the translated state in all other places in the UI, you don’t need it on the one place developers go to see the untranslated states.