thanks!
btw it was this change I referred to, that causes the issue: Release Handle new time zone type in HA core · pnbruckner/ha-sun2 · GitHub
Home Assistant changed the details of its time zone implementation, starting w/ 2021.6.x. Specifically, it switched from the pytz package to Python’s new native zoneinfo library.
as you can see here, I did try the microsecond removal myself, but thought it hacky… though at the time I thought it showed only HH:MM and not :SS too… maybe not.
got another one, new to me so please have a look if I do this correctly:
mqtt topic returns 2021-08-02T20:34:03Z which is Zulu time, as I’ve been explained by Tinkerer, and is also touched atop in this thread.
Now of course I want local time so I can use device_class timestamp, and created this value_template
- platform: mqtt
state_topic: watermeter/smart_gateways/startup_time
name: Watermeter Startup time
value_template: >
{{value.split('Z')[0]}}
device_class: timestamp
and yes, that returns alright. I was wondering though if I shouldn’t be doing an official time manipulation instead if this string manipulation.
thanks for having a look
{{ as_datetime(value)|as_local }}
should work, nowadays, doesn’t it?
thanks!, but no it doesnt. this is what I had:
and this is what your suggestion renders without it being set as timestamp:
with timestamp:
Indeed. I’m always confused about what device_class: timestamp actually expects.
I redid the test, and the UTC time correctly display in my local TZ w/o transformation.
Are you saying that the UTC time returned by MQTT is not actually UTC but local?
Then, it’s just wrong, and you have to “correct” it manually, indeed, no magic here.
OTOH, there might be a setting on whatever sends the message to set the correct TZ…
no the Z time is Utc alright, and local is +2
if I simply take the value and use timestamp I get this:
confuses me even more, because that seems to be correct…
ill reboot the device and see what happens…
right:
so Ive got to go back to the original then
thanks Taras, that too is 2 hours off…
this is really odd:
though the top 3 seem identical in the states, only the split(‘Z’) has the correct local time
- platform: mqtt
state_topic: watermeter/smart_gateways/startup_time
name: Watermeter Startup time
value_template: >
{{value.split('Z')[0]}}
# {{as_datetime(value).isoformat()}}
# {{value}}
# {{as_datetime(value)|as_local}}
device_class: timestamp
Where is it 2 hours off? The example I posted, using the datetime string you provided (Zulu time = UTC), clearly shows the resulting ISO8601 string remains as UTC.
It converted this:
2021-08-02T20:34:03Z
to this:
2021-08-02T20:34:03+00:00
Doesn’t really make sense.
The plain value works for me:
test_timestamp:
value_template: "2021-08-03T20:34:03Z"
device_class: timestamp
Just to be sure, “2021-08-03T22:34:03+02:00” doesn’t mean you have to add 2h to “22:34”. “+02:00” is the TZ, so that datetime is 22:34 in my TZ, UTC+2
The problem for you is when you remove the z and use as_datetime, it removes UTC and treats it as local. That means, it’s not really a zulu timestamp.
what would be the exact remark I should bring across to the author here…
what is still confusing me is, that the Z is correct for the Utc time is 2 hours behind my zone, and when using that it shows the correct time difference.
My issue is to show that Z time in my local time
yes, in the template editor, but did you also use it in the frontend and using device_class: timestamp?
separate topic, trying to use the {{as_datetime(0|timestamp_utc).isoformat()}} jinja template in JS.
Python uses dt.utc_from_timestamp(0)
please help me translate this?
Having a hard time here, because the online tutorials dont use the jinja used here…
thanks
This Template Sensor:
water_meter_test:
friendly_name: Watermeter Startup time
value_template: "{{ as_datetime('2021-08-02T20:34:03Z').isoformat() }}"
device_class: timestamp
looks like this in Developer Tools > States:
and like this in the frontend:
Popup:
I’m sure this is a simple thing, but I can’t figure this one out.
I want to compare the time from a sensor attribute to the current local time in minutes. The outputs for now() and the attribute are:
Now: {{ now() }}
Attribute: {{ state_attr("sensor.my_sensor_name","LastUpdated") }}
displays:
Now: 2021-08-05 10:30:00.001533+01:00
Attribute: 2021-08-05T10:29:41Z
Both seem to show about the same time with the attribute being 19 seconds behind now, which is what I expect. If I convert both of those with as_timestamp, I get:
Now as timestamp: {{ as_timestamp(now()) }}
Attribute as timestamp: {{ as_timestamp(state_attr("sensor.my_sensor_name","LastUpdated")) }}
displays:
Now as timestamp: 1628155860.00095
Attribute as timestamp: 1628159441.0
This for some reasons is showing a difference of 3581 seconds. I’m assuming this is because of daylight savings and my current local time is +1, but I don’t want to just use a hacky -3600 bit of maths as this will break each time we switch from daylight savings. Where am I going wrong?
From a pure datetime perspective, it is correct.
Likely, whatever produced the “LastUpdated” attribute is wrongly configured, and thinks the date/time it has is utc rather than utc+1.
Oh dear - so no way to fix it at my end?
Well, what provides “LastUpdated”. Isn’t there a TZ config at that end?
Most likely, but it’s actually an external REST API that I am calling, so I don’t have control over it.
It’s actually a debate that Z means zulu time. There are references on wikipedia that state Z means zulu time, which apparently is GMT or UTC1, and there are references that state it means zero i.e. UTC. Either way, it seems that the user needs to figure this out for their application.