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.
Look at the trigger times and the update timestamp:
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 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.
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)
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.
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.
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.
I’ve never had a computer device, beside a cam, which had issues with the (local) time
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
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);
If You are in another timezone, then may-be yes
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.
