"Internal" time wrong

I used this initially:

but then I used this:

But the last time the sensor was tripped was 20:22, thus for me 2 hours ago…

it doesn’t round.

so you mean in 4 minutes from now, at my time 22:22 it will say “2 hours ago”?

EDIT: yes it does:

yep, that’s what will happen.

Ok thank you for your help.

As a moderate user I must say that this is not very handy/understandable/user friendly/clear/whatever comes to that :-). I just want to see “my time” stuff in hass and not a UTC timezone that for me in this location make no real sense… I think this must be aware to the “awesome guys” that make hass?

I would really like to see events and tripped times to my timezone. That not a dumb question is it?

I understand where you’re coming from, but it’s only confusing because of the way that your device is implemented. Anyone who want’s a special time displayed in the interface from a device goes through this and there is 9000 different ways people want to view their time. Some people want AM PM, some people only want minutes, some people want it spelled out… see where this is going?

For example, my motion sensors do not have a special attribute called ‘last_tripped_time’. They just turn on and off. HA handles the times by using the last_updated and last_changed state object properties. (giving you the ability to use the last_changed secondary row). Your sensor is unique because it doesn’t do that. Apparently when your sensor trips, it doesn’t send an update to the main state, effectively making last_changed or last_updated useless.

Sorry, I don’t see where you are going :-). time is time, nothing fancy is it? I don’t care about AM/PM, written or sung, but I DO care about the correct ZONE. Nevertheless, thank you and I hope it will be picked up in the future.

Yes, but you seem to not understand. The more-info page is showing you unaltered attributes. It (home assistant) does not know it’s a time. So it keeps it unaltered. That’s up to the user to make use of the attribute.

If that is coming straight from your device, then your device needs to use the local timezone. And if thats something that you can’t set, then you can make a request to the integration to put that time in local timezone. Or do what everyone else does and convert the time. There’s a number of threads that cover how to do that. Here’s one:

Ok I see now that I don’t know what I don’t know. I’ll read on. thanks again!

Hi, another question regarding this topic…

what if I wanted this:

Tried this:

        friendly_name: "Last Motion in BMW"
        value_template: "{{ state_attr('switch.motion_sensor_5_1493', 'last_tripped_time') }}"
        device_class: timestamp
        friendly_name: "Last Motion Voordeur"
        value_template: "{{ state_attr('binary_sensor.sensor_hal_voorkant_beweging', 'last-changed') }}"
        device_class: timestamp

But clearly I have not yaml knowledge :frowning:

you must have an error there in the logs… use last_changed instead, and use it like this:

{{ states.binary_sensor.sensor_hal_voorkant_beweging.last_changed }}

you cant template last_changed using the states() method

yes, seems to work now, thank you!


sure, welcome.

you should understand why though, so read up on this: https://www.home-assistant.io/docs/configuration/state_object/

last_changed isn’t an attributes you can call using state_attr()

Hi, read it. but I do not understand what you mean with
last_changed isn’t an attributes you can call using state_attr()

using state_attr() you can reference all attributes of the state.

in your case eg:


which you can also write as


this is also explained here: https://www.home-assistant.io/docs/configuration/templating/#states

be sure to read the yellow Warning bit, as it will help you write safer templates.

if you want to see which attributes are available for you entity, just throw this at the template editor:


you’ll notice ‘last_changed’ isnt listed. because it is no ‘attribute’.

1 Like

On a RaspPi 3, HassOS 3.13

{{ utcnow() }}
{{ now() }}
{{ utcnow().astimezone() }}
{{ now().astimezone() }}
{{ utcnow().tzinfo }}
{{ now().tzinfo }}
{{ now().astimezone().tzinfo }}

I get

2020-05-19 01:53:12.396476+00:00
2020-05-18 20:53:12.396624-05:00
2020-05-19 01:53:12.396790+00:00
2020-05-19 01:53:12.398530+00:00

Any idea why the astimezone() are all messed up?

check out this

1 Like

Hello Everybody!
Looks like I have a similar issue with time settings. I think you are all running in circles not finding the correct issue.
I say this because:
I am running home assistant supervised in an esxi VM. Installed using 3.13 vmdk image.
Since I installed it a few days ago, I have had a lot of problems, by losing access to the server. I saw it was losing its ip address.
So after reading a lot of topics, I found that the timestamps in supervisor logs are of by 3 hours.
This time delay will F*** up the dhcp renewal from my router (pfsense vm) and after the minimum lease time of 2 hours, the home assistant machine loses its IP and I have to power cycle it. Simple reset will not solve the issue.

Now, I would like to ask you if there is any way to correct this issue. It is driving me crazy, and until now I did not manage to find a way to set the supervisor time/timezone.

Thank you,
And here is my original topic on this forum: Hassio on esxi losing IP address - HA supervised
And here is the issue on Github: https://github.com/home-assistant/operating-system/issues/684

1 Like

Similar problem here??

{{ now() }}
{{ now().astimezone() }}
{{ utcnow().astimezone() }}
{{ now().now() }}
{{ now().today() }}
{{ now().utcnow() }}
{{ utcnow() }}
{{ now().tzinfo }}
{{ now().astimezone().tzinfo }}
{{ utcnow().tzinfo }}

2022-11-12 15:12:40.501943+00:00
2022-11-12 09:12:40.501943-06:00
2022-11-12 09:12:40.501943-06:00
2022-11-12 09:12:40.501943
2022-11-12 09:12:40.502947
2022-11-12 15:12:40.502946
2022-11-12 15:12:40.502946+00:00
Central Standard Time

System Health

Version core-2022.2.3
Installation Type Unknown
Development false
Supervisor false
Docker false
Virtual Environment false
Python Version 3.9.10
Operating System Family Windows
Operating System Version 8.1
CPU Architecture AMD64
Timezone America/Chicago

This automation is going off at 8AM UTC, not 8AM CDT:

  • id: ‘1651526240883’
    alias: Time - Fountain On
    description: Turn on the fountain
    • platform: time
      at: 08:00:00
      condition: []
    • type: turn_on
      device_id: e96adb89d8978094879aca474a5f009a
      entity_id: switch.on_off_outlet_45_c4_8f_bottom
      domain: switch
      mode: single

seems like something isn’t correct?