Log Time and Device Event Time Issue

When an event is recorded in the log the time matches my local time. The problem is the device event is recorded at +4-hours ahead.

Log
[dev:40]2019-06-09 01:49:46.603 pm [info]Smoke/CO Downstairs battery is 94%

Device Event
battery 94 % Smoke/CO Downstairs battery is 94% DEVICE 2019-06-09 05:49:46.605 PM EDT

Platform version 2.1.1.114

I have rebooted and performed complete shutdowns of my hub multiple times but the error doesn't get corrected. Is there an offset setting somewhere to correct this?

+1 exact same problem. @pseudonym I'm guessing you're on the East Coast, cuz I'm Central Time and +5 hours ahead. In others, we're both indicating UTC. Just like you, my local time and UTC seem to get intermingled at the device level. Not good.

I have rebooted, et al, as well. Same problem.

See my post here Time stamp bug? . Bug, but it's a display bug, nothing functioning wrong, events will still fire at the correct time.

ah, good to know. I hadn't. Thanks Patrick.

Has this issue been fixed or is there someway to manually try and sync the time because I am having an issue with my startup procedure rule which contains delayed actions. For some of the rule the time is one thing, and for the other part it is something else. As a result when they delayed action is first triggered, in the incorrect old time, it has a delay for 4 minutes for example. Then the hub time gets updated and it goes beyond those 4 minutes, causing the delayed action to never trigger.

Any ideas on how to fix this?

Alternatively, is there any way to have a wait condition for an update on the time?

Update: I figured out a workaround using the community app shown below. It has the same issue as the delay in that there is an out-of-date and in-date time, but I am guessing it is an greater than or equal to comparison versus just an equal to comparison, which in my case is perfect since the delay is controlling a network device, and an update in time would mean that the internet is up and running.

Yes, the underlying HE bug that the OP and I were discussing was fixed. Sounds like you may be having a different problem though. Assuming you are using RM, if you post the rule, a lot of people around here can help you troubleshoot it. What are you trying to accomplish?

So I have ATT UVERSE fiber, and as a result I am forced to use their gateway with my router cascaded. But upon a little further research there is a way to completely bypass the gateway by spoofing the MAC address of the gateway onto the router and connecting the ONT/Router/Gateway into a unmanaged switch; this allows the gateway to be used only for first time verification and then all traffic is then forwarded directly from the ONT to the router. This verification however is lost upon power loss. So I am trying to find a way to have the internet automatically restored on power loss, without having two devices of the same MAC address on the network at a given time.

The solution I have currently is putting the gateway onto a smart plug which turns on when the hubitat turns on, and then after 4 minutes, 3 minutes is how long verification takes, the gateway is powered off, disconnecting it from the network and transferring control to the router. The issue is that the delay action uses system time, which gets updated when the internet gets restored and screws the entire delay up.

Like I edited my post above, it seems to be working with a community app, probably due to a slightly different handling of delay from the base Hubitat implementation.