5 comments

[ 3.5 ms ] story [ 29.9 ms ] thread
Wow, using the current timezone is not a planned feature.
Thanks for posting this. Seems I am not the only one who ran into this.
I ve got the same automation but I had come to a problem that I always wake up when all shutters start to close automatically. So I stopped doing it automatically which kills a bit the idea
I wanted to help so I took a look at the issue and the code. I was unable to reproduce the issue from your description.

Firstly, issue #153175 refers to the "time of day" sensor, which is not what you're using - you're using the "time" trigger. The TOD code does a bunch of timezone acrobatics that can be fixed, but I don't think it'll affect your problem.

Secondly, I built a tiny regression test on dev (on top of 333a3421) to reproduce your problem, and it didn't repro. I created a "trigger: time, at: 06:00:00, Europe/Paris", attached it before the DST transitions, and checked when it fires before, during, after the DST actual. The trigger fires perfectly on 06:00 walltime, and adjusts utc to match.

Thirdly, the HASS UI has a small bug where it shows "Paris/+1" even if it's currently DST. It's a UI bug only, but it can lead to someone thinking that the entire HASS core doesn't respect DST.

Silly tech support questions - are you on latest? Did you try playing around with {{now()}} in developer templates? Maybe open a new issue?

Why change the timezone using YAML instead of directly from the UI, if you used the UI for everything else? I'm not trying to victim-shame, it's still unacceptable that all the settings were lost.