Open BetterAutomations opened 1 year ago
Looks like you should have Observer(-82, 30)
instead of Observer(30, -82)
.
Anyway, still think that the library should not throw if the dusk time does not exist, because the input is valid. You should probably return None
instead, or some custom values if you want to distinguish "the Sun is always up" and "the Sun is always down".
No, I had it correctly. Observer() is latitude/longitude and the location is 30 latitude and -82 longitude.
Oh... sorry for my mistake. Looks like I've written about another thing instead.
BTW, looks like the 'dusk' time is not on that day you enter acts funny. Either it return the dusk of the previous/next sun rise (on the specified day) or return an error if that of the previous/next day is also not on the day you specify.
To add to the injury the calculations appear to be in UTC instead of local time, so the library crashes even in normal conditions.
Did anything ever get figured out on this issue. I recently started having the same issue, for a location that definitely experiences dusk. Seems to be an issue in >=3.0 versions (for me). Python 3.10
Never found a fix. I switched to the suntime library instead.
I got caught up on this as well. Proof of concept code that won't run:
from astral.sun import sun from astral.geocoder import database, lookup from astral import LocationInfo from datetime import datetime, timezone
location = lookup("London", database()) # Use any city as a temporary placeholder location.latitude = 31.1442757 location.longitude = -88.9690628 s=sun(location.observer, date=datetime(2023,3,10,4,5,2,tzinfo=timezone.utc)) print(s["dawn"]) print(s["dusk"])
I've found a peculiarity in the code anyway: when it tries to find the sunrise/sunset time (or other times), it tries to find the sunrise/sunset at that exactly 24-hr window (in case of DST events, 23 or 25 hours).
Unfortunately, due to a range of factors (e.g. the longitude is not a multiple of 15°), the sunrise/sunset time can actually be in the previous day or the next day. I believe that we should simply use the out-of-day time right away, but astral tries to find the time of the previous or next sunrise/sunset to fit in that 24-hr window. If there is no such sunrise/sunset in the previous/next day, astral throws a ValueError.
The 24-hr window is calculated in the timezone you supplied, so unsurprisingly @chipguyhere 's code does not return the right result - his time zone supplied has almost 90° difference from the longitude, which translate to almost 6 hours.
I had the same issue with version 3.2 of astral, definitively it raised the "no dusk error" when the civilian dusk's (the default one) time is 00:00 UTC or midnight in UTC timezone, doesn't matter the seconds after the midnight. I tested with version 2.2 and it works
For a particular location within the southeastern United States on some days, requesting an astral.sun generates a ValueError, but on previous and following days in the same location, the correct values are returned. This location always experiences dusk.
I only need sunrise and sunset so I attempted to use astral.sun.sunset alone, but this causes the same issue to appears on a different day, but warning that it is "Unable to find a sunset time". I do not recall exactly which day but it was within April.
Tested another library (suntime) and it handled this location with all days in 2023 without any issues.
Sample code:
Output: