>>> city = LocationInfo("Tromsø", "Norway", "Europe/Tromsø", 69.66, 18.82)
>>> s = sun(city.observer, date=datetime.date(2021, 7, 16))
Traceback (most recent call last):
 File "/home/andre/.local/lib/python3.8/site-packages/astral/sun.py", line 734, in dawn
   return time_of_transit(
 File "/home/andre/.local/lib/python3.8/site-packages/astral/sun.py", line 343, in time_of_transit
   hourangle = hour_angle(
 File "/home/andre/.local/lib/python3.8/site-packages/astral/sun.py", line 243, in hour_angle
   HA = acos(h)
ValueError: math domain error

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/home/andre/.local/lib/python3.8/site-packages/astral/sun.py", line 1150, in sun
   "dawn": dawn(observer, date, dawn_dusk_depression, tzinfo),
 File "/home/andre/.local/lib/python3.8/site-packages/astral/sun.py", line 739, in dawn
   raise ValueError(
ValueError: Sun never reaches 6.0 degrees below the horizon, at this location.
>>> 

Instead of error and all, it would be much nicer to return one additional parameter like
s['polar'] "na" or "day" or "night"

Hello.

After installing astral with pip3 command (pip3 list returns --> astral 2.2 ), I cannot move forward from the code:

`#!/usr/bin/env python3

from astral import LocationInfo
`

as I receive error:
Traceback (most recent call last): File "astral.py", line 3, in <module> import astral File "/home/pi/python-scripts/astral.py", line 4, in <module> from astral import LocationInfo ImportError: cannot import name 'LocationInfo' from 'astral' (/home/pi/python-scripts/astral.py)

This is a noob question, but I don't have a solution? Thank you.

I work in Alaska - we are careful about distortions introduced by certain spatial reference systems. I'm wondering which spatial reference that astral uses? Specifically we're using the Astral.solar_elevation() method.

The setup.py file imports the init.py to get the version, but the import fails because pytz is not installed.

Collecting astral from git+https://github.com/sffjunkie/astral.git@master#egg=astral (from -r requirements.txt (line 73))
  Cloning https://github.com/sffjunkie/astral.git (to master) to /tmp/pip-build-isievuvt/astral
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "src/astral.py", line 75, in <module>
        import pytz
    ImportError: No module named 'pytz'
    
    During handling of the above exception, another exception occurred:
    
    Traceback (most recent call last):
      File "<string>", line 20, in <module>
      File "/tmp/pip-build-isievuvt/astral/setup.py", line 11, in <module>
        from astral import __version__ as astral_version
      File "src/astral.py", line 77, in <module>
        raise ImportError(('The astral module requires the '
    ImportError: The astral module requires the pytz module to be available.

My recommendation is to put the code in another file and use the init.py for the version.
Another option is to put the version in the setup.py

Using the example at https://astral.readthedocs.io/en/latest/ when I put my latitude and longitude in the returned times are completely off.

`#!/usr/bin/python3

import datetime
from astral.sun import sun
from astral import LocationInfo
from astral.location import Location
city = LocationInfo("London", "England", "Europe/London", 51.5, -0.116)
pbmo = LocationInfo("Poplar Bluff", "Midwest", "US/Central", 36.873512, -90.488008)

print((
f"Information for {city.name}/{city.region}\n"
f"Timezone: {city.timezone}\n"
f"Latitude: {city.latitude:.02f}; Longitude: {city.longitude:.02f}\n"
))

s = sun(city.observer, date=datetime.date(2020, 2, 11))
print((
f'Dawn: {s["dawn"]}\n'
f'Sunrise: {s["sunrise"]}\n'
f'Noon: {s["noon"]}\n'
f'Sunset: {s["sunset"]}\n'
f'Dusk: {s["dusk"]}\n'
))

print((
f"Information for {pbmo.name}/{pbmo.region}\n"
f"Timezone: {pbmo.timezone}\n"
f"Latitude: {pbmo.latitude:.02f}; Longitude: {pbmo.longitude:.02f}\n"
))

s = sun(pbmo.observer, date=datetime.date(2020, 2, 11))
print((
f'Dawn: {s["dawn"]}\n'
f'Sunrise: {s["sunrise"]}\n'
f'Noon: {s["noon"]}\n'
f'Sunset: {s["sunset"]}\n'
f'Dusk: {s["dusk"]}\n'
))
Running this results in:john@d10cave:~/gitlocal/coop2$ ./sun2.py
Information for London/England
Timezone: Europe/London
Latitude: 51.50; Longitude: -0.12

Dawn: 2020-02-11 06:47:32.053221+00:00
Sunrise: 2020-02-11 07:23:12.648323+00:00
Noon: 2020-02-11 12:14:41+00:00
Sunset: 2020-02-11 17:06:54.384574+00:00
Dusk: 2020-02-11 17:42:38.338837+00:00

Information for Poplar Bluff/Midwest
Timezone: US/Central
Latitude: 36.87; Longitude: -90.49

Dawn: 2020-02-11 12:28:12.640188+00:00
Sunrise: 2020-02-11 12:55:27.838617+00:00
Noon: 2020-02-11 18:16:10+00:00
Sunset: 2020-02-11 23:37:22.438327+00:00
Dusk: 2020-02-12 00:04:38.943368+00:00
`

Thanks for Astral, I've been using it in my current chicken coop to open and close the door for a couple of years now. Just upgrading the new coop to Python 3 and Astral 2.

JT

Hi.
Shouldn't be theta1 and not alpha the depression adjustment? In the Effect of elevation image on index.rst I think the depression angle should be the one between C-B-and the horizontal:

which is theta.
And you'll see that if elevation tends to infinity theta tends to 90 degrees but alpha only to 45 degrees which doesn't make much sense to me. I think the adjustment could be theta.

The documentation does not specify what units are used for elevation. Is it feet or meters?

Would you accept PR adding more cities to AstralGeocoder?

Hi,

For one of our project we want to use astral to determine sun course and all the great stuff provided by astral. The only thing is: we are completely offline, and want to keep our python env light.

As we are never going to use all the GoogleGeocoder feature (no network), it would be really nice to make the dependency on requests optional: right now, if we don't install requests, we cannot even load Location or Astral with the default AstralGeocoder which does require AFAICS connectivity...

Would it be possible to only raise an error if we try to instanciate a GoogleGeocoder in case that requests is not installed?

We are very careful with which dependencies we integrate, and requests package with all its dependancies is a big waste of space...

Thanks!

I started getting this error about a week ago (getting close to summer solistice I'm guessing) for a location that's fairly up north, but nowhere near the pole - lat,lon = 62.55,-129.52.
I've traced it back to the following code:

    def _hour_angle(self, latitude, declination, depression): 
        # arg values: 62.54999923706055, 21.466634091977532, 96 
        latitude_rad = radians(latitude)
        declination_rad = radians(declination)
        depression_rad = radians(depression)

        n = cos(depression_rad)
        d = cos(latitude_rad) * cos(declination_rad)
        t = tan(latitude_rad) * tan(declination_rad)
        h = (n / d) - t   # h: -1.0006730127306969 <- out of range for acos

        HA = acos(h)    # Exception here. 
        return HA

I'm not sure how to handle this. Is astral not supposed to work in my case?

When I use Location.rahukaalam It's returning tuple of 2 values for the day time. Is there a way to get night time rahukaalam using this API ?

Location.sun etc will default to the system date if it's not specified. I think it should take tz into account if local=True?

I hit this issue today in NZ, where the clocks just changed. Calculated dawn (etc) was off by 1 hour since the machine tz wasn't the same the location tz, therefore this morning the date was defaulting to yesterday, and therefore wasn't using daylight saving.

I found the following bug, which results in incorrect calculations.

>>> import astral
>>> from astral.geocoder import database, lookup
>>> lookup("Phoenix", database())
LocationInfo(name='Phoenix', region='USA', timezone='America/Phoenix', latitude=33.43333333333333, longitude=-112.06666666666666)

The longitude for "America/Phoenix" should be POSITIVE 112.06, not negative. The coord. from LocationInfo. above are somewhere in China.

I'm fairly certain that zenith angle is supposed to be measured in degrees from vertical, not degrees from the horizon. Mind if I fix this and make a PR?

my application call this funtion every day at 00:01 to update the dusk-dawn data:

def init_light_schedule():
    city = LocationInfo("Tromsø", "Norway", "Europe/Tromsø", 69.66, 18.82)
    s = sun(city.observer)  # , s=datetime.date(2021, 2, 18))

    dawn = (s['dawn'] + datetime.timedelta(hours=1))  # negative hours gives earlier "off"
    dusk = (s['dusk'] + datetime.timedelta(hours=1))  # positive hours postpone "on"
    dawn = dawn.replace(tzinfo=None)  # remove timezone info
    dusk = dusk.replace(tzinfo=None)
    now = datetime.datetime.now()
    # for testing now = datetime.datetime(2021, 2, 17, 2, 00)
    print(time.strftime('%H:%M:%S'), ', light schedule updated')
    print('dawn: ', dawn)
    print('dusk: ', dusk)

but the output does not show new data, it is displaying the data of the first day of the script run:
21:37:08 , light schedule updated <<<<< initial run (manual start)
dawn: 2021-03-01 06:08:20.148169
dusk: 2021-03-01 17:47:39.511878
00:01:00 , light schedule updated <<<< the function was executed on schedule, produced the same time(and date)
dawn: 2021-03-01 06:08:20.148169
dusk: 2021-03-01 17:47:39.511878

For the 1.8 tag, there is no corresponding release on https://pypi.org/project/astral/#history.

Melbourne is the 3rd biggest Australian city by size, and second by population. It belongs on the list. So, something like:

Melbourne,Australia,-37°48'S,144°57'E,Australia/Melbourne,31

Probably Darwin too… (We have 8 states, not 6) Already in the list:

Adelaide,Australia,34°56'S,138°36'E,Australia/Adelaide,50
Brisbane,Australia,27°30'S,153°01'E,Australia/Brisbane,25
Canberra,Australia,35°15'S,149°08'E,Australia/Canberra,575
Hobart,Tasmania,42°53'S,147°19'E,Australia/Hobart,4
Perth,Australia,31°56'S,115°50'E,Australia/Perth,20
Sydney,Australia,33°53'S,151°13'E,Australia/Sydney,3

I created #5 to change from urllib to requests.

Yes this does add another package to the requirements but its a common package and fixes some major OSX issues.

As we all know, today more than ever before, it is crucial to be able to trust our computing environments. One of the main difficulties that package maintainers of GNU/Linux distributions face, is the difficulty to verify the authenticity and the integrity of the source code. With GPG signatures it is possible for packagers to verify source code releases quickly and easily.

Overview of the required tasks:

• Create and/or use a 4096-bit RSA keypair for the file signing
• Use a strong, unique, secret passphrase for the key
• Upload the public key to a key server and publish the full fingerprint
• Sign every new Git commit and tag
• Create signed, compressed (xz --best) release archives
• Upload a strong message digest (sha512) of the archive
• Configure HTTPS for your download server

GPGit

GPGit is meant to bring GPG to the masses. It is not only a Python script that automates the process of creating new signed Git releases with GPG, but also a quick-start-guide for learning how to use GPG. GPGit integrates perfectly with the Github Release API for uploading.

The security status of GNU/Linux projects will be tracked in the Linux Security Database. If you have any further questions, do not hesitate to contact me personally. Thanks for your help in making GNU/Linux projects more secure by using GPG signatures.

Thanks in advance.

Hard coding paths in your setup.cfg breaks installing under buildout.

It's also surprising when using simple python setup.py build If build attempted higher in the file system, they could try to write in / (or above!).

Suggest you remove those lines from prod distributions.

The US cities list should include large cities:

San Diego,29.4724°N 98.5251°W
San Antonio, 29.4724°N 98.5251°W
San Jose, 37.2967°N 121.8189°W
Fort Worth, 32.7815°N 97.3467°W
El Paso, 31.8484°N 106.4270°W
Tucson,32.1531°N 110.8706°W
Fresno,36.7836°N 119.7934°W
Mesa,33.4019°N 111.7174°W
Colorado Springs,38.8673°N 104.7607°W
Long Beach,33.8092°N 118.1553°W
Oakland,37.7698°N 122.2257°W
Tulsa,36.1279°N 95.9023°W
Tampa,27.9701°N 82.4797°W
Arlington,32.7007°N 97.1247°W

https://en.wikipedia.org/wiki/List_of_United_States_cities_by_population

At a higher elevation (meters above sea level) the sun rises earlier than at lower elevations. This is not implemented in astral 1.6, even though the Location class has an elevation attribute.

>>> import astral
>>> low = astral.Location(('A', 'B', 46.95, 7.47, 'UTC', 500))
>>> low.sun()['sunrise']
datetime.datetime(2018, 3, 12, 5, 49, 47, tzinfo=<UTC>)
>>> high = astral.Location(('A', 'B', 46.95, 7.47, 'UTC', 4000))
>>> high.sun()['sunrise']
datetime.datetime(2018, 3, 12, 5, 49, 47, tzinfo=<UTC>)

After update to 2.1 code "from astral import Astral" is not working anymore.

Before it was working with code like:
from astral import Astral
a = Astral()
a.solar_depression = 'civil'

I don't see anything in change-log. What a non pleasant surprise !

There seems to be an issue with the solar elevation calculation, it doesn't seem to match the results given by time_at_elevation.

It can be off by up to six mins at times. I have submitted a test case that demonstrates the issue.

Possibly related to #7 and #34.

Thanks for the effort, astral is a great piece of work,very much appreciated.
I did some calculations with it and compared the results with some diaries one can buy in bookshops as well as with moon phases calendar, such as this one:
https://www.timeanddate.com/moon/phases/?year=2019
They all agree and slightly disagree with astral's calculations, sometimes there is a shift, always max. 1 day compared with the others. I've also observed it yields the very same moon age for two consecutive calendar days before such a skew happens, so I guess it is because of the integer return value of the moon phase. Tried to go for float return value but no matter what I pass for rtype, I always get int.

This function can also be written a lot more simply.

ldo-julianday.patch.txt

However, I am little uncertain as to the correctness of the value. I have other code that returns a value 1 greater than this.

Please add a lookup of the moon phase name.

A suggestion of doing this is by returning a string for a float value:

• phase < 1 returns New moon
• phase >= 1 and phase < 7 returns Waxing crescent
• phase >= 7 and phase < 8 returns First quarter
• phase >= 8 and phase < 14 returns Waxing gibbous
• phase >= 14 and phase < 15 returns Full moon
• phase >= 15 and phase < 21 returns Waning gibbous
• phase >= 21 and phase < 22 returns Last quarter
• phase >= 22 returns Waning crescent
• the rest returns an empty string

Implementation should support localization of the names via gettext. Implementation could even be in exiting method moon_phase() when rtype=str.

PS The exact values above should be reviewed by someone with more in-depth knowledge of this subject.

I'm getting this error with astral==2.0.1 (also with the 2.0.2 tag, and with latest master 60aa65f) when trying to calculate sun data from NZ:

"ValueError: Sun never transits at a zenith of 96.0 on 2020-02-11"

Example:

from astral.geocoder import database, lookup
from astral.sun import sun
import pprint

london = lookup("London", database())
pprint.pprint(sun(london.observer))

outputs something reasonable:

{'dawn': datetime.datetime(2020, 2, 11, 6, 47, 1, 656555, tzinfo=<UTC>),
 'dusk': datetime.datetime(2020, 2, 11, 17, 42, 13, 415600, tzinfo=<UTC>),
 'noon': datetime.datetime(2020, 2, 11, 12, 14, 14, tzinfo=<UTC>),
 'sunrise': datetime.datetime(2020, 2, 11, 7, 22, 40, 881412, tzinfo=<UTC>),
 'sunset': datetime.datetime(2020, 2, 11, 17, 6, 30, 837342, tzinfo=<UTC>)}

wellington = lookup("Wellington", database())
pprint.pprint(sun(wellington.observer))

hits this exception

Traceback (most recent call last):
  File "/home/johnc/.PyCharm2019.3/config/scratches/scratch_10.py", line 11, in <module>
    pprint.pprint(sun(wellington.observer))
  File "/home/johnc/.virtualenvs/sureflap_gcloud/lib/python3.7/site-packages/astral/sun.py", line 1123, in sun
    "dawn": dawn(observer, date, dawn_dusk_depression, tzinfo),
  File "/home/johnc/.virtualenvs/sureflap_gcloud/lib/python3.7/site-packages/astral/sun.py", line 738, in dawn
    observer, date, 90.0 + dep, SunDirection.RISING
  File "/home/johnc/.virtualenvs/sureflap_gcloud/lib/python3.7/site-packages/astral/sun.py", line 380, in time_of_transit
    raise ValueError(f"Sun never transits at a zenith of {zenith} on {date}")
ValueError: Sun never transits at a zenith of 96.0 on 2020-02-11

Hey guys, do you know how Astral algorithms are compared to PySolar?

Hello,

Thanks for this great module!

I would like to request better error handling for this project. As it stands, whenever anything goes wrong in the module only a ValueError is thrown (e.g. 'Sun is always above/below the horizon at this location on this day')

I'd like to request that custom Exceptions be raised for these various events (e.g. SunAlwaysAboveHorizonException or similar). This will allow for much more robust and consistent error handling. Right now, the only thing I can do is parse the error message and that is very dirty and prone to problems as you update the module.

Alternatively, logging a warning plus creative use of datetime.min and datetime.max could potentially be used to not raise an exception at all but still return a usable date range for comparisons.

Hi,
I would like to use Astral for daylight calculations. I installed Astral with conda-forge (my conda version is 4.8.2) and I got Astral version 1.9.2. How can I get the last version? Also, when I run command from astral import sun I get the following error:

ImportError: cannot import name 'sun'

Any idea?

Getting a moon phase of 24 but there is no info on what string that phase number relates to.

Using version 1.6

Up in the arctic circle, in July during the midnight sun, when looking for the next sunrise and sunset the next sunrise seems to happen before the next sunset. This shouldn't be possible.

I'm sorry but I don't understand the maths enough to fix it. I think this might be related to the next issue I'm submitting and will link to here.

As part of refactoring remove all Python 2 support?

sudo pip install astral==2.1

Could not find a version that satisfies the requirement astral==2.1 (from versions: 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.6.1, 0.6.2, 0.7, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.7.5, 0.8, 0.8.1, 0.8.2, 0.9, 1.0, 1.1, 1.2, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.4, 1.5, 1.6, 1.6.1, 1.7, 1.7.1, 1.8, 1.9, 1.9.1, 1.9.2, 1.10, 1.10.1)
No matching distribution found for astral==2.1

if installing without version, the 1.10 is installed and, as I understand, they are not compatible.

[raspberry pi 3, python 3.5]

Reference to the work by PanderMusubi to be added to docs see https://github.com/PanderMusubi/lunar-phase-calendar/ to highlight generating Unicode glyphs for the moon phases as well as translation of pahse names to other languages.

Hi!

I've come across a case where astronomical dusk is reported but there is no astronomical dawn following that dusk which, I suppose, should always be the case.

I suspect it has to do with the sun barely reaching 18 degrees below the horizon.

The following program illustrates the issue. Specifically, astronomical dusk occurs on 2017-05-03 at time 01:29:52+02:00 (at the specified location) but there is no astronomical dawn on the same day.

import astral
import datetime

location = astral.Location(("Test name", "Test region", 56.1629, 0, "Europe/Berlin", 0))
date = datetime.date(2017, 5, 3)

location.solar_depression = "astronomical"
yesterday = date - datetime.timedelta(1)
print("Astronomical dusk: " + str(location.dusk(yesterday)))
print("Astronomical dawn: " + str(location.dawn(date)))

I used Python 2.7.12 and Astral 1.3.4.

I had problems getting all the functions to run. I found that some worked and others didnt depending on the way astral is imported.

Some of errors I received were
"module 'astral' has no attribute moon_phase"
"type object 'Astral' has no attribute 'location' "

import astral - gets the location attribute to work
from astral import Astral - got the moon_phase and most other functions working

To get both, manual location, and moonphase working I had to do both.
import astral
from astral import Astral
ast = Astral()

now both of these will run without errors
nyemoon = ast.moon_phase(date=datetime.date(2020,1,1))
location = los_altos = astral.Location(info=("Los Altos", "USA", 37.3681,
-122.0975, "US/Pacific",50))

The solar elevation calculation doesn't take the altitude into account. It seems to me like it should adjust using _depression_adjustment, while solar_zenith should be modified so that it ignores altitude.

This might be related to #35 possibly?

Sorry for all these issues without any patches, I don't really understand the maths enough to fix it.

I found, that moon phases are slightly off by several hours. I'm using astral to calculate moon phases, bus since astral gives inaccurate values, sometimes I get moon phase for a wrong date.

Here is my experiment:

import datetime
import ephem
import astral
import matplotlib.pyplot as plt
x = [datetime.datetime(2020, 5, 22) + datetime.timedelta(hours=i*6) for i in range(30*4*2)]
a = astral.Astral()
a = [a.moon_phase(date=d, rtype=float) for d in x]
a = [(28 - p if p > 14 else p) / 14 * 100 for p in a]
e = [ephem.Moon(ephem.Date(d)).phase for d in x]
fig, ax = plt.subplots()
ax.plot(x, a, label="Astral")
ax.plot(x, e, label="Ephem")
ax.legend()
plt.show()

And the result:

Tried the package with city_name = 'Berlin'

The calculated values for dawn are always the same, no matter what value solar_depression has ('civil', 'nautical' or 'astronomical').

Here the code-snippet:
`from astral import Astral
LOCATION = 'Berlin'

a = Astral()
a.solar_depression = 'civil'
city = a[LOCATION]
print(LOCATION, city.region, city.timezone)
sun = city.sun(date=arrow.now(), local=True)
print(sun)`

and the output (print sun) for 'civil'

{'dawn': datetime.datetime(2019, 1, 29, 4, 1, 26, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>), 'sunrise': datetime.datetime(2019, 1, 29, 7, 52, 54, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>), 'noon': datetime.datetime(2019, 1, 29, 12, 19, 19, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>), 'sunset': datetime.datetime(2019, 1, 29, 16, 45, 44, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>), 'dusk': datetime.datetime(2019, 1, 29, 20, 37, 12, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>)}

and for 'nautical':

{'dawn': datetime.datetime(2019, 1, 29, 4, 1, 26, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>), 'sunrise': datetime.datetime(2019, 1, 29, 7, 52, 54, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>), 'noon': datetime.datetime(2019, 1, 29, 12, 19, 19, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>), 'sunset': datetime.datetime(2019, 1, 29, 16, 45, 44, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>), 'dusk': datetime.datetime(2019, 1, 29, 20, 37, 12, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>)}

and for 'astronomical':

{'dawn': datetime.datetime(2019, 1, 29, 4, 1, 26, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>), 'sunrise': datetime.datetime(2019, 1, 29, 7, 52, 54, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>), 'noon': datetime.datetime(2019, 1, 29, 12, 19, 19, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>), 'sunset': datetime.datetime(2019, 1, 29, 16, 45, 44, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>), 'dusk': datetime.datetime(2019, 1, 29, 20, 37, 12, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>)}

The values for dawn and dusk are far to low/high. The correct values should be (UTC-Time from https://sunrise-sunset.org):

{'results': {'sunrise': '2019-01-29T06:52:06+00:00', 'sunset': '2019-01-29T15:46:55+00:00', 'solar_noon': '2019-01-29T11:19:31+00:00', 'day_length': 32089, 'civil_twilight_begin': '2019-01-29T06:14:41+00:00', 'civil_twilight_end': '2019-01-29T16:24:21+00:00', 'nautical_twilight_begin': '2019-01-29T05:33:16+00:00', 'nautical_twilight_end': '2019-01-29T17:05:46+00:00', 'astronomical_twilight_begin': '2019-01-29T04:53:12+00:00', 'astronomical_twilight_end': '2019-01-29T17:45:50+00:00'}, 'status': 'OK'}

I think this issue is different from, but relates to, issues 9 and 34 .

I need to compute solar elevation and solar noon for a high latitude location (lat = 70, long= -139), but calling sun (as per the documentation) returns the error "ValueError: Sun never reaches 6.0 degrees below the horizon, at this location". That statement is correct in the summer, but solar noon does happen and there is a solar elevation at that time.

Is there any way to compute just these parameters using astral?

For the astral.Location.twilight(...) function, the direction and date arguments here are swapped.

Example under Timezones group

from astral.geocoder import group
europe = group("europe")

Traceback (most recent call last):
File "<pyshell#430>", line 1, in
europe = group("europe")
TypeError: group() missing 1 required positional argument: 'db'

suggested correction to documentation

europre = group("europe",database())

hi
would be interesting to have a function to calculate the 2 Solstices (date and time) so that consequentially is possible to get the max and min elevation / zenith for a given location

def solstice_min(observer) : return datetimeobject

Are there any plan to support MicroPython with a uastral version?

Hi,
I'm upgrading my program from v1.6 to v2.1.
I've notice since the clocks have changed in the U.K. that the time is off by one hour. I think it is the same as (closed) issue #29, but I cannot get this to work.
Here is the code I've been using:

from datetime import date
from datetime import timedelta # Automatically handle day that span over the month

from astral import LocationInfo
from astral.sun import sun

city = LocationInfo('Headley', 'England', 'Europe/London', 51.1211, -0.8297)

today = date.today()
print(today)

for x in range(0, 7):
day = sun(city.observer, today)
print('Dusk: %s' % str(day['dusk']))
print('Dawn: %s' % str(day['dawn']))
today += timedelta(days=1)

Also have the calculations changed between version as irrespective of the hour difference, the times are different by a few minutes.
Any help would be appreciated.

import pytz
import datetime

import astral
import astral.location

tz='UTC'
utc_now = datetime.datetime(2010, 1, 1, tzinfo=pytz.timezone(tz))

obs = astral.Observer(latitude=66.5, longitude=162.4, elevation=0.0)

print(utc_now) # datetime.datetime(2010, 1, 1)

sunrise = astral.sun.sunrise(obs,utc_now)
sunset = astral.sun.sunset(obs,utc_now)
print(sunrise)
print(sunset)

utc_now = sunrise + datetime.timedelta(seconds=15)
print(utc_now) # Adjusted time to just after sunrise

print(astral.sun.sunrise(obs,utc_now)) #Completely different sunrise time, day before, why not same as above?
print(astral.sun.sunset(obs,utc_now)) #Same issue... getting time for previous day.

Produces:
2010-01-01 00:00:00+00:00
2009-12-31 23:53:51.078028+00:00 <==Sunrise Time
2010-01-01 02:33:44.399907+00:00 <==Sunset Time
2009-12-31 23:54:06.078028+00:00 <== Adjust time to Sunrise Time + 15 seconds
2009-12-30 23:55:49.136837+00:00 <== New Sunrise Time
2009-12-31 02:30:47.610544+00:00 <== New Sunset Time

Hi,
I try to build astral for archlinux and got some problems with the recent 1.4.1 tag. You've fixed those issues in the master branch, it would be nice if you could update those.

The issue is the missing setup.cfg which is loaded by version=versioneer.get_version(), and other parts in the setup. Maybe you can just tag a release 1.4.2 (also gpg signed? #10 )

This function can be written a lot more simply.

ldo-proper-angle.patch.txt