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?
A bit tangential. In Israel, case records are sort-of-free.
They're publicly available in a byzantine system maintained by the Court Management, a governmental entity (Net Hamishpat, "court net" - slightly deviating from Beit Hamishpat meaning "the court", https://www.court.gov.il/NGCS.Web.Site/HomePage.aspx), but it is not where cases and material are referenced from in the public sphere or legal docs.
Most professionals subscribe to Nevo (https://www.nevo.co.il/), which is a "repository" of cases, law (updated to the latest revisions) etc. Even official court documents say "as seen in Nevo". They sometimes release tidbits of info to the common (unregistered) man, but searches etc are paywalled. There are other similar systems from other companies.
It seems that Nevo and co are slurping the material via a sliding-window (~7 days back) doc-dump that the Court Management lets people access as long as they commit to removing cases that the Court Management tells them to remove.
There is one renegade (Tola'at Hamishpat, "court worm" https://xn----8hcborozt8bdd.xn--9dbq2a/) which is not using this doc-dump and instead scrapes the gov website. They're doing it to not be bound by the agreement for removing documents, which they say they'll only do if they get forwarded a court order that the case is now classified. This is because the Court Management, which is not populated by judges but rather admin people, sometimes instructs removal of cases too freely (without a court order), which clouds the principle of public availability according to the Tola'at operators.
There are other sites which purport to allow free access to cases, but they're usually low-level scrapers and don't allow a full-enough view.
As an "information wants to be free" person, I find this entire saga fascinating.
Referring purely to the article and not to the title (which is hard, because I see a lot of people are, and it is tempting), I can say that I disagree with 1 (Using AI means you don’t learn as much from your work).
At least personally, using codegen LLMs allows me to step into areas I'm completely unfamiliar with, produce value, and learn new things along the way. I just made changes to a FOSS Android app I'm using, and I'm relatively inexperienced in mobile. However, now I know soe Kotlin keywords, I know a bit about the UI libs, and know better how to build and test Android code.
So I think I don't learn less, maybe I learn the things that interest me.
Life led me to consultancy to tech oriented companies, and I can say that like the father at Charlie and the Chocolate Factory (film), I make more money fixing the machine than I did doing the work the machine is now doing.
From what I saw, people might be able to produce code faster, but at least for now its design frays heavily at the edges (scaling, resiliency, security).
On back to school, I can personally report that I tried that and gave up because uni knowledge cramming felt much more boring compared to learning work-related stuff.
It has restricted internet, and allows calls and messages only to / from other "Kosher" lines and specific whitelisted numbers as approved by a rabbinical committee.
They also have some bastardized support for Whatsapp with a limited ability to join groups (not sure how that's implemented)
I'm an independent software architect. Companies bring me in for the painful infra and backend projects their team can't get to without derailing core work, usually migrations, reliability fixes, and cost takeouts.
Recent: AWS to GCP migration saving $5K/month with zero downtime. Cassandra to DynamoDB migration, no downtime. Build times 30min to 3min, success rate 70% to 97%. Once replaced a planned 2-month rewrite with a 6-line diff.
Background: 6 years at Facebook (reliability/performance/security at billion-user scale), then architect at two growth-stage startups. Independent since 2025.
Best fit: growth-stage company with a defined infra-shaped problem and budget to have someone senior own it end-to-end. Probably not the right call for ongoing IC work or pure feature delivery. I work fixed-price when scope is clear, hourly when it isn't.
To me, since the DB is there to serve the app (which is there to serve the user), the lookup/enum decision mostly depends on whether the list is defined before build time (> enum) or after (> lookup).
US states are probably a solid "before", so you get the added value of easily materializing a validator in the app code.
Children IDs sound a bit more dynamic.
I've been working on this for the couple of last months. I found this project to have multiple tech angles (pcb, electronics, C-level ESP, Python, webui / Javascript, machine vision), an figured it might be an interesting read.
I don't think anyone did anything similar to this, and maybe people would like the idea and make their own e-ink poster
Is Django's ORM even supported outside Django sites?
I had a consulting gig that had a FastAPI website using Django's ORM and it produced a bunch of weird bugs.
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?