I have an Automation called “Kids Bedroom All Off @ 9:15” which turns off a number of devices in the kids bedroom at 9:15 in the morning. This automation is executing at 2:15 am which matches the 7hr offset of Italian time where I was between June 14th and June 30th. I am not sure whether I modified the automation while there, as I was looking at what to disable while I was away, however it appears that the automation picked up the new time zone and is now executing at 2:15 am local time (CST) which is 9:15 am (CET) in Europe. While I was in Italy, my phone was connected to my local network in Texas via VPN which may have somehow messed things up making the hub think the local time was what my phone was on.
The logs, after my return also appeared to still be using CET time and a reboot of my Samsung S20 Ultra appears to have fixed that issue.
Speaking of which, it was very frustrating to have all the logs of location events switch from local time (CST) where the event took place, to the time where I was (CET >> +7hrs). It makes a lot more sense to have (location) local timestamps for events instead of them picking up the (temporarily) remote location time. In other words, imagine if you have an automation that triggers at sunrise, sunset, midnight or some other time, and the timestamps don’t match the correct time (of the location) but rather use the local time where you are at… While the calculation is simple, it is unnecessary and makes it harder to read/understand at a glance.
Last… while not completely incorrect… can we please abandon the use of (ie) 24:12 and use the more common 0:12 to indicate 12 minutes past midnight? I grew up in Europe so I have always used the 24hr system and have never seen midnight something reported as 24:xx. I know some countries do it (like South Korea) but I have also read that the more standard approach is to use 0 (zero) for midnight.
I posted a version of the above in centercode but since the beta is closed I wonder whether the correct ST engineer will see it.