Repository navigation
Fix hour-angle and geometric event conversion on DST transition days - #2923
Open
kadyrbekovhamit-cyber wants to merge 2 commits into
Open
kadyrbekovhamit-cyber wants to merge 2 commits into
kadyrbekovhamit-cyber wants to merge 2 commits into
Conversation
Hey @kadyrbekovhamit-cyber! 🎉Thanks for opening your first pull request! We appreciate your If AI is used for any portion of this PR, you must vet the content Finally, be sure the PR description includes the PR |
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.
On DST-transition days, elapsed time since local midnight differs from the local clock time.
hour_anglealready subtracts the UTC offset at each input timestamp, so combining it with elapsed hours can introduce a 15-degree discrepancy. Geometric sunrise/set conversion has the corresponding one-hour shift.Use naive local wall-clock subtraction for the forward calculation, and construct the inverse UTC instant from the date, wall-clock hours and timestamp-specific offset. This also avoids an ambiguous/nonexistent local midnight. The return types and function signatures remain unchanged. Related #2132/#2133 addressed midnight handling; this proposal addresses the remaining numerical discrepancy.
Regression validation on current main 0c6ab77: six transition/ambiguous-midnight checks fail before and pass after. The complete test_solarposition.py module has 65 passes and 21 skips (optional dependencies unavailable), versus 59 passes, six failures and 21 skips before. Current solarposition.py and tests ran over the existing pvlib installation; not a full source install or full project suite. No measured annual-production or financial-loss claim.
Prepared by Xamit Kadirbekov and Daniyal Kadirbekov with Codex/ChatGPT assistance for investigation, patch, tests and writing. Synthetic tests use a direct UTC hour-angle equation and timezone-invariance checks.
NonExistentTimeErrorwhen callinghour_angle#2132 and Handle time normalization for nonexistent and ambiguous times #2133, which are not reopened or claimed as resolved here.docs/sphinx/source/referencefor API changes.docs/sphinx/source/whatsnewfor all changes. Includes link to the GitHub Issue with:issue:`num`or this Pull Request with:pull:`num`. Includes contributor name and/or GitHub username (link with:ghuser:`user`).remote-data) and Milestone are assigned to the Pull Request and linked Issue.Documentation CI follow-up (24 October)
Read the Docs build 35380797 failed. Its raw log reports ten gallery-example failures in
pvlib/iotools/tmy.py:226,ValueError: Cannot modify read-only array, plus downstream undefined-variable errors in the clearsky guide. Thetmy.pyGit blob is identical on the base and this branch. I have not run a complete documentation build on the base, so I am not claiming that the whole CI pipeline is clean. The scoped solar-position regression results above remain unchanged.