Fix get_astral_location deprecation warning#859
Merged
craigbarratt merged 1 commit intoJul 3, 2026
Conversation
Member
|
Thanks for the PR; much cleaner now! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
sunrise/sunsettriggers usedsun.get_astral_location(), which HA deprecated (removal in 2027.7) and warned on every use. Switched to the higher-levelsun.get_astral_event_date(), which avoids the deprecated API entirely and needs no version fallback.This also restores
elevationsupport, which was inadvertently dropped in 300a633 when a localget_astral_event_datecopy omitted theobserver_elevationargument. No behavior change at the default elevation of 0; existing tests pass.On dropping
async_add_executor_job: the executor wrapping was added in 884c428 (PR #610) to move the blockinglocation.sunrise()/sunset()calls (timezone data loaded from disk) off the event loop. That's no longer needed here:get_astral_event_date()is a HA@callback(loop-safe by contract, and called synchronously by HA itself), and it computes inUTC- the local conversion uses the timezone already cached at startup viadt_util.as_local(). So the call runs directly on the loop without reintroducing the blocking I/O.Fixes #858.