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