Last updated timestamp relative time reported as "in 7 hrs"

[dbell68]

Hubitat C-7 with platform 2.3.1.140 and Home Assistant Container with HACS-Hubitat 0.7.1.

I have both Sonoff and Aqara sensors connected to hubitat hub, and on both entity cards in HA the last update time is reported as "in 7 hrs". I am -0700 from UTC, and the log data for both is correct in hubitat, so I don't think it is the raw data on the hubitat side that is incorrect.

I think the TZ offset is being applied to the actual raw data value as it comes into HA from which the card relative time is then calculated. I even created a template sensor to reverse the delta and get the correct relative time display:

{{ (as_timestamp(states('sensor.xxxx_last_update_time')) | float - (7x60x60)) | timestamp_local }}
Note: used x to indicate multiply to avoid markdown formatting with asterisk

All other time info in the environment is displayed accurately so I believe Hubitat (US/Pacific) and HA (America/Los_Angeles) are both set correctly from a TZ config point of view.

I searched and didn't find anything like this; please advise what log / debug info would be useful.

[jason0x43]

The last update time is something managed entirely by the extension; it doesn't come from Hubitat. Any time the extension receives an update from Hubitat for a particular device, it updates the device's "last_update" state value with the current epoch time using Python's time.time() function, which is TZ-independent. The Last Update Time sensor's state value is the device's last_update value converted to an ISO 8601 formatted UTC string.

HA should handle converting the state string to the system's local timezone for display. For example, I'm in the US Eastern TZ. I have a motion sensor in my office that was just triggered a few seconds ago. It's Last Update Time sensor's state value is 2022-04-22T01:57:00.624228+00:00 (1:57am on the 22nd, UTC), and the entity card shows 9:57pm on the 21st (which is the correct local time):

[dbell68]

Hey thanks for getting back to me. This is what I see in the dev states display for a device: 8.38pm pacific is definitely not 10.38am UTC, but it is 14 hrs different (i.e. double the TZ offset) and then on the entity card I see this: I should add I am relatively new to HA but in no universe is a last updated time in the future relative to my time.

[dbell68]

So I see on this display that it looks correct even if not in my local TZ, which is what you had shared above: But then I see this example, where the displayed time matches the future offset: Just seems all over the place; can the cards have individual TZ config info associated with them ?

[dbell68]

Just for good measure, here are all the last update times for devices in hubitat, they are all in the future by 7 hrs, except for the template I created to deduct 7 hrs to get back to pacific: P.S. The date / time in the HA container are UTC and are correct.

[jason0x43]

Hmmm...so, is the last update timestamp correct, regardless of how it's being displayed on cards, or is it actually a future value? If it's a future value, then the issue may be in the container that's running the integration. The integration is simply using Python's time.time() function to get a timestamp, and the correctness of that depends on the configuration of the system running Python.

You could try this, just to make sure the basics are working: on the HA host (the container that's actually running the integration), open Python and run python -c 'import time; print(time.time())'; this will print out a floating point timestamp, like 1650628585.6345081. Then, on your normal desktop system, run date -r 1650628585 (with the integer part of the timestamp). Is it the current time?

[dbell68]

From inside the HA container:

/config # date
Tue Apr 26 00:41:55 UTC 2022
/config # python -c 'import time; print(time.time())'
1650933719.7841804
/config # TZ='America/Los_Angeles' date '@1650933719'
date: can't set date: Operation not permitted
Mon Apr 25 17:41:59 PDT 2022
/config # date '@1650933719'
date: can't set date: Operation not permitted
Tue Apr 26 00:41:59 UTC 2022

and then from an entirely different machine:

date --date='@1650933719'
Mon Apr 25 05:41:59 PM PDT 2022

[jason0x43]

Just checking in; is this still an issue? All of the date commands above seem to be reporting consistent results (UTC by default, or the proper local time otherwise).

[jason0x43]

Since there hasn't been an update in a while, I'm closing this out. Feel free to reopen if the issue is still occurring.