Two nasty surprises in Home Assistant's config | Hacker News Reader

Two nasty surprises in Home Assistant's config

blog.frankel.ch

42 pointsedward10 comments

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.

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

Wow, using the current timezone is not a planned feature.

The GitHub issue was "closed as not planned" due to stalebot auto-closing it, not because the maintainers actually said "we don't plan to do it".

IMHO stalebots are an anti-feature in an issue tracker, and do more harm than good, but that's a different discussion.

After 3 months.

Maintainers ignored the issue for 3 months until their own automation closed it. It wasn't a rogue github bot.

I've seen issues ignored for a lot longer than 3 months because maintainers didn't have time, then when they did have time they addressed the issue. Heck, Svelte recently did a PR fixing a bug report from about 4 years back. I'll see if I can dig it up. 3 months is not enough time, in my experience, to decide that the maintainers of an open-source project aren't interested in fixing an issue.

EDIT: I'm not finding the issue that I'm thinking of very quickly. But it was a bug report from 2022 which they looked at at the time, said "yeah, this is an issue we'd like to fix but we don't have a good fix right now", and then the issue was silent. Later on, Svelte went through a major internal rewrite between Svelte 4 and Svelte 5. With Svelte 5's new internals, they were able to fix that 2022 issue. I noticed it because I had just recently read the Svelte changelog, idly clicked on some of the PRs, and noticed an issue with a very low number that was marked as fixed. But I'm not finding it now.

Which is exactly issue with stalebot. 3 months of no movement on an issue is not and should not be a reason to close it. The issue is real and this ensures it wont get fixed.

Issues waiting for far longer then 3 months before they are fixed is super normal of important but not a blocker category of bugs.

Claude Code has an even shorter policy. https://github.com/anthropics/claude-code/issues/16497

Thanks for posting this. Seems I am not the only one who ran into this.

Reply on news.ycombinator.com