[Bug] Local time is set to UTC time after firmware update + reboot

I installed v.7.4.2 two days ago on Homey Pro (previously running v7.4.2-rc.8).
I noticed some time triggered scenes ran much later, or ran twice.
It happened to be exactly 2 hours.

Screenshot from 2022-06-25 00-47-19

Look at the trigger times and the update timestamp:

Local time was set to UTC…

.
I just got some flow messages which triggered at 23:59h.
Also a few testflows were 2hrs late:

.
I went over to the developer page and it says UTC and human time are equal, now local time has become UTC time…?


The mobile app however, still displays the correct local time. I killed the app, cleared cache, restarted my cellphone, but no change…

Solution (for now):
I changed my location to Canada, and now the local and UTC time both were correct.
After changing it back to my timezone, the local time was also correct again.

I experienced the same issue a while ago. Changed my location to England and changed it back. For me it was in 7.4.1.

I wonder if Athom will revert the SDK3-change of “everything UTC” in SDK4 because it turns out dates and times are still too difficult for them :joy:

1 Like

I just don’t understand why this is a thing. Just let users select their timezone. Shouldn’t be so hard. I do understand their wish to keep it as simple as possible and their thrive to push for a global market. But selecting a timezone with a suggestion based on localization shouldn’t be that difficult. And maybe I just don’t get the problem and it is much more complicated.

1 Like

No, it’s not. In fact, it makes things more complicated because by running everything in UTC you have to convert everything back to local time manually because users want a flow card that triggers at 2AM to trigger at 2AM local time, not UTC.

Linux system clocks always run in UTC because it makes it easy for the user to change their local timezone. And by setting the timezone, all apps and programs that use time/date functions will get those in local time (unless they explicitly request UTC time), as expected. Makes perfect sense. When I log in on a remote server hosted wherever, by setting the timezone properly in my shell all programs will show times in my local timezone.

However, Athom seems to know better than the rest of the world and have removed timezone support for apps (and, judging by how the issue that @Peter_Kawa ran into keeps popping up, on a Homey core level as well), causing all sorts of grief for app developers that need to handle local times.

(and to preempt the yes-men: no, “but Homey Cloud!” is not a valid reason)

1 Like

There is also still a problem with long days in Norway, , when " when it is night" starts after midnight… I have to invert the function in the summer… Reported it back in 2020, no solution yet.

1 Like

Maybe the clocks tick differently in the Netherlands… :wink:

image

Homey FW v7.4.3

This is a bug that keeps popping up for some users, and has done so for quite a while now. It’s not related to v7.4 but to firmware updates in general.

1 Like

I know that some users having a problem with this, and that’s not a good.
But I still don’t understand why some core problems appear only for some users and not for all.

These types of issues are generally caused by race conditions, where you have multiple parts of the system starting up in parallel while one may depend on the other, or where a certain order in which operations are running is required but not enforced. So usually the system will start up in the right order, but not always, which could cause the problem.

So a Homey restart can solve problems, but it can also cause problems?!
And that can’t be brought under control?

Yes, although this particular problem seems to be limited to firmware updates.

Apparently not, given how long this issue has existed (I think from when SDK3 was introduced).

image

Maybe it’s due to the forced update, my auto-update always works perfect.

I’ve never had a computer device, beside a cam, which had issues with the (local) time :see_no_evil:

Me not like auto update hehe.
Like Robert wrote, it appearantly happens sometimes to some Homey’s since the change to UTC …
I just have to check the local time after a reboot I guess :no_mouth::woozy_face:

Script and a flow:

A 15 minute 45 minute wait, to give Homey a chance😉
(HomeyScript did not run yet after 15mins)

// datum_opvragen.js
// UTC time
var date = new Date(); 
// Get human date info
let SysInfo = await Homey.system.getInfo(); 
// Extract local time
var localTime = SysInfo.dateHuman.slice(SysInfo.dateHuman.indexOf(' ')+1); 

UTClocaltime = ("UTC_Time: " + date + "; Local_Time: " + localTime);

// Create Homeyscript Tag/Variable UTC-and-Local-time
await tag("UTC-and-Local-time", UTClocaltime);

console.log(UTClocaltime);

return(true);
1 Like

Prepaired like this, it will probably never happen again :rofl:

1 Like

Hehehe, I bet that’s true!!

If You are in another timezone, then may-be yes :wink:
There may be some interference with Homey, Athom web server and also Your local browser (which one also wants to give a timezone info for client side scripts).
NB! Yes, i know, by the book the Athom web servers must not to touch the traffic (authentication is a separate thing), but suspecting, there is little bit more from Athom, not from my local Homey, on my browser’s page.

Naah, this has been going on since the very beginning (just search the old forum), it just that some updates are more prone to it happening for some reason.
The more popping up now is probably just because of more users.

Didn’t know that, thanks!

Well, the monitor flow did it’s work :smiley:

1 Like