It’s UTC.
Under general settings
1 Like
How does this datetime string indicate it’s with respect to UTC?
1970-01-01T00:00:00
This would indicate it’s UTC.
1970-01-01T00:00:00+00:00
^^^^^^
Without the offset information it’s naive (i.e. timezone is unknown).
Try this in the Template Editor:
{{ now() - as_datetime(0|timestamp_utc) }}
It won’t allow the calculation because the second datetime object is naive.
Trying but I can’t get the last_reset_value_template in the mqtt sensors to work unfortunately.
Can anybody here try please?
It was not a general scope exercise: the objective was calculating UNIX epoch 0 in ISO 8601 format.
This is enough, and it works for the scope:
{{ as_datetime(0|timestamp_utc).isoformat() }}
output: 1970-01-01T00:00:00
If you do want to make it strict (mind that ISO 8601 is not a strict standard as many think, there’s a lot of debates on the topic) it’s sufficient to add the Z at the end:
{{ as_datetime(as_datetime(0|timestamp_utc)|string+‘Z’).isoformat() }}
Output: 1970-01-01T00:00:00+00:00
And this works too:
{{ now() - as_datetime(as_datetime(0|timestamp_utc)|string+‘Z’) }}
18843 days, 20:42:00.004621
Sorry to quote this again, but I don’t understand the yaml anchors;
If I add that the default yaml config, won’t this overwrite the entities that have a correct “last_reset” value?
I don’t have MQTT sensors, sorry. 
It should use the currency you configured in “General Configuration” settings.
1 Like
Perhaps there has been a misunderstanding. If you look at my original post, my advisory was meant to caution users about the template’s suitability for certain applications. I did not question its suitability for your specific application (or the extent of its adherence to ISO 8601).
The template’s result is a naive version of the Unix Epoch so it has certain limitations, notably it can’t be used in datetime calculations with an aware datetime object. However, contrary to what my original post stated (and is now corrected), it is interpreted correctly for use in a timestamp sensor.
BTW, why does this specific application require using a template to compute the Unix Epoch when it’s a known value and can be stated as a string?
I edited my reply to you including an aware version of the template, now it works in any case. Please read it again. Sorry for the misunderstanding, my bad. 
Read from this post on for a few posts, basically Franck pointed me to this for lifetime energy sensors’ attribute last_reset recommended value:
I simply translated that API call in a template as an exercise, that’s it.
I haven’t installed 2021.8.0 yet, so I can’t test it, but wouldn’t Home Assistant’s ‘native typing’ handle this correctly?
last_reset: "{{ '1970-01-01T00:00:00+00:00' }}"
It works properly in a timestamp sensor (the result of this is the same as in the screenshot I posted above):
unix_epoch:
friendly_name: Unix Epoch
value_template: "{{ '1970-01-01T00:00:00+00:00' }}"
device_class: timestamp
This worked:
last_reset: ‘1970-01-01T00:00:00+00:00’
Franck initially said no, but then he corrected himself explaining why it worked: Home Energy Management in 2021.8 - #5 by frenck
1 Like
This requires 2021.8? Why?
{{ now() - as_datetime(as_datetime(0|timestamp_utc)|string+‘Z’) }}
Doh! Of course the template wasn’t needed. 
Native typing infers the value’s type whether it’s a constant or generated by a template.
I meant I can’t test the suggestion with the last_reset option because I haven’t installed 2021.8 yet.
Isn’t the output of a template always a string?
Sorry, 2nd misunderstanding.
Yes, as far as the Jinja2 processor is concerned but then the string is assigned a type based on its appearance (the ‘native typing’ introduced several versions ago). My mistake was hanging around templates for too long and doing silly stuff like
whatever: "{{ 'cat' }}"
instead of simply
whatever: 'cat'
Luckily I’m still “young” in HA world, so I learned soon you can do whatever: 'cat'. That’s about the only advantage of not being an expert like you, I don’t yet have old habits. 
you should of course adapt it to your own entity naming. Since I named my energy sensors with that suffix, it was an easy customize. you can use the exact same anchor on an individual entity, or even a fake entity, and inject it with the * anywhere.
for anyone struggling with the mqtt last_reset topic (and the techniques as explained in the docs dont work): see Can't set last_reset value for MQTT sensor · Issue #53988 · home-assistant/core · GitHub
tip from BergCyrill in the core issue: publish payload “1970-01-01T00:00:00+00:00” with retain flag to a fake topic and use that as retain topic in your mqtt sensor config:
unit_of_measurement: kWh
value_template: >
{{value|round(2)}}
last_reset_topic: 'fake/last_reset'
# last_reset_value_template: >
# {{'1970-01-01T00:00:00+00:00'}}
# {{as_datetime(0|timestamp_utc).isoformat()}}
device_class: energy
state_class: measurement
2 Likes
Thanks for sharing, I consider this to be a workaround as well, like the customize_glob method. So I’ll just stick with that for now