"Internal" time wrong

Configuration
81

So i had the same thing, was driving me crazy cause I would get notifications from the future, not sure if you’re on Ubuntu but I am and ended up running “timedatectl status” then got a warning about how ```
The system is configured to read the RTC time in the local time zone.
This mode can not be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
‘timedatectl set-local-rtc 0’.

so i ran the command and rebooted and this has fixed my time being off for a little bit under boot up. 
timedatectl set-local-rtc 0

hope that helps
82

hey @pnbruckner,

Any thoughts on the above post of why the mobile browser (ipad + ios + ios app) shows results differently from desktop chrome?

iPad Chrome:

image
image2360×1010 147 KB

Mac Chrome:

image
image2364×1000 142 KB

template sensor yaml:

    deadbolt_last_unlocked_by_guest:
      value_template: >-
        {{ as_timestamp(states.input_datetime.airbnb_deadbolt_unlocked_by_guest_user_3.last_changed)|timestamp_custom('%Y-%m-%d %H:%M:%S.%f-07:00') }}
      friendly_name: 'Last Unlocked by Guest'
      device_class: timestamp

    deadbolt_last_unlocked_by_guest_2:
      value_template: >-
        {{ states.input_datetime.airbnb_deadbolt_unlocked_by_guest_user_3.last_changed }}
      friendly_name: 'Last Unlocked by Guest'
      device_class: timestamp


    deadbolt_last_unlocked_by_guest_ib:
      value_template: >-
        {{ as_timestamp(states.input_boolean.airbnb_deadbolt_unlocked_by_guest_user_3.last_changed)|timestamp_custom('%Y-%m-%dT%H:%M:%S.%f%z') }}
      friendly_name: 'Last Unlocked by Guest'
      device_class: timestamp

    deadbolt_last_unlocked_by_guest_ib2:
      value_template: >-
        {{ states.input_boolean.airbnb_deadbolt_unlocked_by_guest_user_3.last_changed }}
      friendly_name: 'Last Unlocked by Guest'
      device_class: timestamp

lovelace yaml:

    - entity: sensor.deadbolt_last_unlocked_by_guest
      secondary_info: last-changed
    - entity: sensor.deadbolt_last_unlocked_by_guest_2
      format: relative
      secondary_info: last-changed
    - entity: sensor.deadbolt_last_unlocked_by_guest_ib
      format: relative
      secondary_info: last-changed
    - entity: sensor.deadbolt_last_unlocked_by_guest_ib2
      format: relative
      secondary_info: last-changed

values:

<template state sensor.deadbolt_last_unlocked_by_guest=2019-12-30 09:36:23.739773-07:00; friendly_name=Last Unlocked by Guest, device_class=timestamp @ 2019-12-30T09:36:33.357120-08:00>

<template state sensor.deadbolt_last_unlocked_by_guest_2=2019-12-30 17:36:23.739773+00:00; friendly_name=Last Unlocked by Guest, device_class=timestamp @ 2019-12-30T09:36:33.348726-08:00>

<template state sensor.deadbolt_last_unlocked_by_guest_ib=2019-12-30T09:36:23.750513-0800; friendly_name=Last Unlocked by Guest, device_class=timestamp @ 2019-12-30T09:36:33.353989-08:00>

<template state sensor.deadbolt_last_unlocked_by_guest_ib2=2019-12-30 17:36:23.750513+00:00; friendly_name=Last Unlocked by Guest, device_class=timestamp @ 2019-12-30T09:36:33.355626-08:00>
83

Interesting. Thanks for sharing. I wasn’t aware of this situation. I’m also on Ubuntu and when I run timedatectl status it shows:

RTC in local TZ: no

So I didn’t have this issue. But good to keep in mind.

84

Sorry, no, I don’t have any answers for the previous post.

But for this post, for starters, can you explain why each of the four template sensors manipulate the time differently? Why are you using last_changed as is with two, but changing the other two first to timestamps, then converting to strings in the local time zone, but with one having -07:00 appended and the other using %z? I don’t understand why you’re changing last_changed at all with those two.

85

All I’m after is for the last_changed value to be shown the same in both mobile and desktop UIs. This is just my running tally of the various things that I’ve tried to get it to work. Initially, IIRC, it was showing one as UTC and the other as PST, so I tried to see if I could fix it with the 7 hour PST offset, but that didn’t work. I’m just confused why I’m getting two different results from two different devices even though the code is the same.

86

Maybe we should take a step back, because I’m at least confused now about what you have in your config and the results you’re seeing on the two devices. Also, let’s take the frontend out of the picture for now and start with concentrating on the backend first.

Please put the following in the Template Editor, on both devices, and post what you get. Then we can take it from there:

{{ utcnow() }}
{{ utcnow().astimezone() }}
{{ now() }}
{{ utcnow().tzinfo }}
{{ utcnow().astimezone().tzinfo }}
{{ now().tzinfo }}
{{ states.input_datetime.airbnb_deadbolt_unlocked_by_guest_user_3.last_changed }}
87

I totally don’t get it… below screenshot I tripped my motion sensor and took the screenshot…
the time is 18:35 and the tripped time in the sensor is 16:35… and the

  - entity: switch.motion_sensor_5_1493
    secondary_info: last-changed

gives:
image

image
image2110×1217 35.5 KB

What do I need to do to get the correct time for “last tripped time”?

this is the states:

image
image780×370 10.6 KB

I am on hassos

image
image1801×297 8.92 KB

please help…

88

Is your local time zone +2:00? If so, there’s nothing wrong with the last_tripped_time, which is represented in UTC.

What browser are you using to see HA’s UI? What is the OS that it is running on? What are the time settings (i.e., time & time zone) on that system?

89

Hi, it has nothing to do with my browser, nor OS. But for completeness, I have windows 10 (up to date) and Firefox, Edge, Chome, etc. All same behavior. And it is also the case in the official home assistant app (which is also a browser (?)):

Screenshot_20200505-191751_Home Assistant
Screenshot_20200505-191751_Home Assistant1080×2280 141 KB

I am located in NL:
image

And according to my homeassistand container it is correct that I must be in Asmterdam:

image
image1275×249 6.4 KB

And some extra info:
image

90

I wouldn’t be too sure. It is my understanding that the “3 hours ago” part is determined by the browser, and is based on the OS’s time settings. Clearly the last_tripped_time attribute is correct, so that’s not the problem.

What do you get if you enter this into the Template Editor:

{{ states.switch.motion_sensor_5_1493 }}
{{ states.switch.motion_sensor_5_1493.last_changed }}
{{ states.switch.motion_sensor_5_1493.last_updated }}
91

It is. It is not, everything appears to be UTC. It basically subtracts javascript datetimes: new Date() - new Date('string'). The string has the timezone, so the discrepency is coming from new Date() which is essentially datetime.now() in python.

EDIT: Just confirmed this btw. The delta is here, so you can see it’s just straight making a new Date() object.

  const compareTime = options.compareTime || new Date();
  let delta = (compareTime.getTime() - dateObj.getTime()) / 1000;
  const tense = delta >= 0 ? "past" : "future";
  delta = Math.abs(delta);

In the current case, options are not set so compareTime results in new Date().

Looking at the code, I would think that the device might be sending the wrong info instead of the browser or os.

92

So something that just occurred to me. I believe the “X ago”/“in X” information is based on the entity’s state’s last_changed field, which indicates the last time the state’s “state” changed, not the last time just one of its attributes (like, in this case, last_tripped_time) changed.

Of course it’s kind of hard to tell from a picture of an entity’s “more info” window, especially when it’s not expanded horizontally, when the state last changed. But going back to the picture that was posted, it does look like maybe the state actually didn’t change for 3 hours. Hence the “3 hours ago”, even though the last_tripped_time attribute had just changed.

So, unless I’ve now really confused myself, I don’t see anything wrong. It’s behaving as I would expect.

If @sender can post the results from the Template Editor like I asked for, that should clear things up.

93

What is “the template editor” I am MORE THAN HAPPY to give everything you guys need to get my correct tripped time displayed.

EDIT:
Found:

<template state switch.motion_sensor_5_1493=off; device_armed=False, last_tripped_time=2020-05-05T18:22:59+00:00, device_tripped=False, Vera Device Id=1493, friendly_name=Sensor Car Motion @ 2020-05-05T15:35:08.874862+02:00>
2020-05-05 13:35:08.874862+00:00
2020-05-05 18:23:00.744940+00:00
95

Ok, you’ll see that both the last_tripped_time and the entity’s state’s last_updated field (the last line) are about the same. But you’ll also notice the state’s last_changed field is about 5 hours earlier. That’s when the switch changed to off. That is the time that is used to display the “X ago” / “In X” line. If you look at the history of the entity, is it saying “5 hours ago” now?

96

image

But I am sure that if i restart homeassitant that is 0… let me try…

97

Yeah, I see the confusion… Last Changed is not the last_tripped that you’re seeing. YOu need to make a template sensor from last tripped to get the correct time it was last tripped. The value in the more-info page is UTC.

sensor:
- platform: template
  sensors:
    car_last_tripped:
      value_template: "{{ state_attr('switch.motion_sensor_5_1493', 'last_tripped_time') }}"
      device_class: timestamp
98

I am sorry, I tried but if you say “you need to make a template sensor” I do not know what to do… can you please help me?

And… do I need to do this then for all sensors? Can’t I just tell haas not tu use the UTC but my timezone?

99

I literally posted the code…

100

Yes, but where do I put it (blush)?

101

If you want the last_tripped_time, yes, you would. No you can’t just tell hass to treat it’s internals as UTC. What you are seeing is a property that’s not meant to be used. If you want to use it, make a template sensor using the code I posted.