Library for computing the sunrise/sunset from GPS coordinates and a date, in Java.
Home Page: http://mikereedell.github.com/sunrisesunsetlib-java/
License: Apache License 2.0
I have problem calculation sunrise time for location N69.8888, E27.0000 for date 2014-01-16. For same date and location, sunset is calculated, but should the sunrise also be possible to calculate. 2014-01-15 sun is not either setting or rising (as expected) in that location.
Test case for testing this behaviour that I used is here:
public class SolarEventCalculatorInNorthTest extends BaseTestCase {
private SolarEventCalculator calc;
@Before
public void setupCalculator() {
super.setup(0,16, 2014, "69.8888", "27.0000", "Europe/Helsinki");
calc = new SolarEventCalculator(location, "Europe/Helsinki");
}
@Test
public void testComputeSunriseTime() {
String localSunriseTime = "12:05";
// should be something near 12:00, but not 99:99 because sun can't set if
// it hasn't rised
String actual = calc.computeSunriseTime(Zenith.OFFICIAL, eventDate);
assertEquals(localSunriseTime, actual);
}
@Test
public void testComputeSunsetTime() {
String localSunriseTime = "12:35";
String actual = calc.computeSunsetTime(Zenith.OFFICIAL, eventDate);
assertEquals(localSunriseTime, actual);
}
}
The following test returns sunrise offset by 30 minutes.
Location location = new Location("19.01441", "72.84794");
SunriseSunsetCalculator calculator = new SunriseSunsetCalculator(location, "Asia/Kolkata");
Calendar calendar = Calendar.getInstance();
calendar.setTimeZone(TimeZone.getTimeZone("Asia/Kolkata"));
String sunrise = calculator.getCivilSunriseForDate(calendar);
I solved this problem by making a few corrections in the getUTCOffSet method (SolarEventCalculator.java). The modified function is given below:
private BigDecimal getUTCOffSet(Calendar date) {
float offSetInMillis = date.get(Calendar.ZONE_OFFSET);
BigDecimal offSet = new BigDecimal(offSetInMillis / 3600000);
return offSet.setScale(1, RoundingMode.HALF_EVEN);
}
The data type of offSetInMillis is changed from int to float and setScale is set to 1. This strikes another point in my head. If the timezone offset is 05:45 (Kathmandu, Nepal), we may need to set the scale to 2. Check out!
Would be great as an addition to also have moon phase added
'not sure how to reference this, but it may be a helpful feature to some use cases as it's third in line for levels of night flying restrictiveness:
"Three different concepts of "night" are referred to in the Federal Aviation Regulations in the US. These include the periods from
(1) sunset to sunrise,
(2) the end of evening civil twilight to the beginning of morning civil twilight (this is the "standard definition of night", given in FAR Section 1.1),
(3) one hour after sunset to one hour before sunrise.
These uses of night are listed in order of increasing restrictiveness. The end of evening civil twilight generally occurs less than one hour after sunset. AirNav is a good source for sunset and sunrise and evening civil twilight and morning civil twilight." -- https://en.wikipedia.org/wiki/Night_aviation_regulations_in_the_US
Mike, I think you'll find that Ed William's algorithm (taken from the Nautical Almanac Office Almanac for Computers, 1990) is a simplified one using constants tailored to 1990 sunrise/sunset.
The generalised algorithm is rather more complex. See e.g. Jean Meeus’ Astronomical Algorithms.
You can see the differences analysed at http://eng.climate.com/2014/04/02/astro-algo-astronomical-algorithms-for-clojure.
Add a feature to query Solar Midnight, similar to Solar Noon.
This is a little bit more tricky for obvious reasons... that it, it may fall in the AM or PM??? If so, perhaps offer both solar midnights before and after the solar noon in an arrary.
I found the solar midnight term used here: http://www.geoffr524.com/NOAA_Solar_Calculations_May_2011/NOAA_Solar_Calculations_May_2011.htm
Robert
In the aviation context... "Night means the time between the end of evening civil twilight and the beginning of morning civil twilight, as published in the Air Almanac, converted to local time." -- http://bit.ly/2iAjV7p
Consider adding isAviationNight() method that includes astrological and nautical time frames in it's coverage.
Add a feature to query solar noon (high noon) for a given day / location.
Provide center/edge toggle when getting Sunrise/Sunset information
This was similarly done with Pyephem; http://rhodesmill.org/pyephem/rise-set.html#computing-twilight
In a military context, BMNT and EENT are used; Begin Morning Nautical Twilight (i.e., Nautical Dawn) and End Morning Nautical Twilight (i.e., Nautical Dusk).
Even though this would be a slight duplicate/split of SunriseSunset.getNauticalTwilight(), consider adding the following two methods, as a military context application would probably only use one or the other method per situation:
.getBmnt();
.getEent();
If local time variable will be less then 0, in method SolarEventCalculator.getLocalTimeAsCalendar(), result will be incorrect.
Hello,
strangewise I get wrong results for sunset, set of civil blue hour on 21. june 2014 for the location 50.93311 - 11.58336.
Only on this day the *set times are miscalculated by 6 hours.
Usually sunset should be around 21:31, but it calculates 15:31 (for official zenith).
When I switch the "isSunRise"-param for the getLongitudeHour-function to "true" it calculates correctly - but I dont think that its a good idea to set isSunRise-param to true for sunset-values :D
Can anyone help fix the bug? Why does it only occur on this day and this location? If I use a location not far away from this, it calculates correctly.
A method to return magnetic directions towards the sun when it is at the center of the horizon for sunrise and sunset would be swell.
This would be fantastic if I was waiting for the sun to come up with a magnetic compass, and not knowing where to look... an app could get this data for me. ALSO, one could set up a video camera with this info and when the sun passes the horizon, it would be perfectly centered. :)
getMagneticDirection([params]) {}
returns values for:
(note that Solar noon and Solar Midnight would have less use but are still of interest, and they would represent the direction the observer would be facing relative to there position (overhead, and out of sight)):
.getMagneticDirection(); // Sunrise
.getMagneticDirection(); // Solar noon
.getMagneticDirection(); // Sunset
.getMagneticDirection(); // Solar Midnight
Given the same time and location, times don't match among Sunrise/Sunset utilities. Please verify that your utility is accurate.
Sunday UTC 6 September 2009
for atlanta (33.8, -84.4)
more specifically (33.766667, -84.416667)
USNO (http://bit.ly/2iPNelk) - (33.766667, -84.416667)
Sunrise: 2009/9/6 11:15:00 UTC
Sunset: 2009/9/6 23:56:00 UTC
sunrisesunsetlib-java - (33.766667, -84.416667)
Sunrise: 2009/9/6 11:15:00 UTC
Sunset: 2009/9/6 23:57:00 UTC
Pyephem (http://rhodesmill.org/pyephem/rise-set.html) - (33.8, -84.4)
Sunrise: 2009/9/6 11:14:57 UTC
Sunset: 2009/9/6 23:56:10 UTC
SunriseSunset (33.766667, -84.416667)
Sunrise: 2009/9/6 11:16:33 UTC
Sunset: 2009/9/6 23:58:17 UTC
http://api.sunrise-sunset.org/ (http://api.sunrise-sunset.org/json?lat=33.766667&lng=-84.416667&date=2009-09-06)
SunriseSunset (33.766667, -84.416667)
Sunrise: 2009/9/6 11:15:27 UTC
Sunset: 2009/9/6 23:55:58 UTC
Would be great if this library would be supported to be run in an OSGi container.
Need urgent help to solve one my critical bug.
Please help me with this.
sunrise time in UTC time is 2020-05-16 is: 00:01
sunset time in UTC time is 2020-05-16 is: 13:36
sunrise time in UTC time is 2020-05-17 is: 00:00
sunset time in UTC time is 2020-05-17 is: 13:37
sunrise time in UTC time is 2020-05-18 is: 00:00
sunset time in UTC time is 2020-05-18 is: 13:37
sunrise time in UTC time is 2020-05-19 is: 23:59
sunset time in UTC time is 2020-05-19 is: 13:38
sunrise time in UTC time is 2020-05-20 is: 23:59
sunset time in UTC time is 2020-05-20 is: 13:39
sunrise time in UTC time is 2020-05-21 is: 23:58
sunset time in UTC time is 2020-05-21 is: 13:39
from the NOAA National Renewable Energy Laboratory Solar Position Calculators
https://www.esrl.noaa.gov/gmd/grad/solcalc/sollinks.html
NREL's Measurement & Instrumentation Data Center provides web based applications for calculating solar and lunar position and/or solar intesity. Please remember that the amount of solar energy received by the Earth is highly variable both in time and space (from location to location), and that these mathematical models cannot be expected to produce an exact replication of any given set of physical conditions.
SOLPOS: SOLPOS calculates the location of the Sun in the sky and its intensity for any given location, day, and time. Valid from the year 1950 to 2050, with an uncertainty of +/- 0.01 degrees.
Solar Position Algorithm (SPA): SPA calculates the location of the Sun in the sky (and various other values). Valid from the year -2000 to 6000, with an uncertainty of +/- 0.0003 degrees.
Solar and Moon Position Algorithm (SAMPA): SAMPA calculates the location of the Sun and Moon in the sky for the purpose of solar eclipse monitoring and for estimating the influence on solar irradiance. Valid from the year -2000 to 6000, with an uncertainty of +/- 0.0003 degrees for the Sun position and +/- 0.003 degrees for the Moon position.
[edited]
Location location = new Location("37.739558", "-122.479749");
SunriseSunsetCalculator calculator = new SunriseSunsetCalculator(location, "America/Los_Angeles");
Calendar sunset = calculator.getCivilSunsetCalendarForDate(Calendar.getInstance());
For date 5/3 it reports 20:31. Actual sunset is 20:03.
Add isTwilight method.
Twilight reference: http://robertjliguori.blogspot.com/search/label/twilight
Add package.html files to support Javadoc
When calculating sunset time for a location in the western hemisphere, there is no 1-day shift for the sunset when it is after the midnight of the timezone used for the calculator.
Location location = new Location("39.9522222", "-75.1641667");
SunriseSunsetCalculator calculator = new SunriseSunsetCalculator(location, "UTC");
Calendar calendar = new GregorianCalendar(2018, 04, 18);
calculator.getOfficialSunriseCalendarForDate(calendar); // 2018-05-18T09:43
calculator.getOfficialSunsetCalendarForDate(calendar); // 2018-05-18T00:12 <--- should be 2018-05-19T00:12
On the other hand, the shift is considered for the eastern hemisphere.
Location location = new Location("39.9522222", "75.1641667");
SunriseSunsetCalculator calculator = new SunriseSunsetCalculator(location, "UTC");
Calendar calendar = new GregorianCalendar(2018, 04, 18);
calculator.getOfficialSunriseCalendarForDate(calendar); // 2018-05-17T23:42
calculator.getOfficialSunsetCalendarForDate(calendar); // 2018-05-18T14:10
Hi
After executing such code for Warsaw/Poland
Calendar calendar = Calendar.getInstance();
SunriseSunsetCalculator calc = new SunriseSunsetCalculator(new Location(52.2297700, 21.0117800), "Poland");
calc.getAstronomicalSunriseCalendarForDate(calendar);
I get null result. As I checked, it's returned by
computeSolarEventTme in:
if ((cosineSunLocalHour.doubleValue() < -1.0) || (cosineSunLocalHour.doubleValue() > 1.0)) {
return null;
}
The algorithm link is outdated since the site seems to be down. The best I could find was:
https://web.archive.org/web/20161202180207/http://williams.best.vwh.net/sunrise_sunset_algorithm.htm
Hi Mike,
I am trying to get the sunrise time for today using your calculator. I have looked at a couple of sources to get the official sunrise time for today and all confirm the time to be about 5:32 AM. When I run the calculator with the same date and location it produces a sunrise time exactly 2 hours behind (3:32AM). The code and setup is as follows:
Location location = new Location("-3.581405","53.284355");
SunriseSunsetCalculator sunriseSunsetCalculator = new SunriseSunsetCalculator(location, TimeZone.getTimeZone("Europe/London"));
String sunriseTimeString = sunriseSunsetCalculator.getOfficialSunriseForDate(GregorianCalendar.getInstance(TimeZone.getTimeZone("Europe/London")));
Does the above code look correct to you? Can you think of any reasons why this would happen with the above code?
The instructions say to download the jar file, but I don't see it in the zip nor anywhere else.
Failed tests:
testRiseAndSetTimes(com.luckycatlabs.sunrisesunset.SunriseSunsetDataTest): Expected: 04:48, but was: 05:48 for date: 4/06/2008
Can you fix it? I want to use your lib
The sunsrise/sunet calculator works good but there is an error in SolarEventCalculator.java which seems to be rounding the TimeZone offset.
private BigDecimal getUTCOffSet(Calendar date) {
int offSetInMillis = date.get(Calendar.ZONE_OFFSET);
BigDecimal offSet = new BigDecimal(offSetInMillis / 3600000);
//Log.e("offset", offSet.setScale(0, RoundingMode.HALF_EVEN)+"");
return offSet.setScale(0, RoundingMode.HALF_EVEN);
}
If I pass "Asia/Kolkata" as the Timezone, which has an offset of UTC + 5.30, this code returns the offset as 5, which in turn causes a major difference in the time output by the program. I tested this by adding a Log to the offset value.
I corrected the error by changing the offSetInMillis in code from int to double and simply returning offSet.setScale(2);
double offSetInMillis = date.get(Calendar.ZONE_OFFSET);
BigDecimal offSet = new BigDecimal(offSetInMillis / 3600000);
return offSet.setScale(2);
Consider adding a method to return the length of the day... this API found it important enough to add...
http://sunrise-sunset.org/api
"day_length":"9:38:53" and "day_length":51444
I think this information is important as for those wanting to see the sunrise or sunset, they could get the complete timeframe of the event ahead of their visit to the beach, bay, desert, whatever, so they could plan accordingly. That is, it happens so fast, every second counts, especially if you are taking pictures or a video. :)
"The time from when the sun first appears in the morning to when it is completely above the horizon (or the opposite in the evening) is about 2 minutes 45 seconds at the equinox. At the solstice or first day of summer and winter the time is about 3 minutes 15 seconds. " -- [i lost the link]
I would recommend returning the value in seconds.
Morning magic hours
Blue hour (from -6° to -4°)
Golden hour (from -4° to 6°)
Evening magic hours
Golden hour (from 6° to -4°)
Blue hour (from -4° to -6°)
Reference: http://www.photopills.com/articles/understanding-golden-hour-blue-hour-and-twilights
I'm seeing production crashes where the Location class is trying to allocate 320kb, presumably for either the latitude or the longitude. Is there a reason why unlimited precision is necessary? Wouldn't double be good enough?
Your link to this webarchive wayback time machine page is no longer valid, on the README page. https://web.archive.org/web/20161202180207/http://williams.best.vwh.net/sunrise_sunset_algorithm.htm.
I think its here now.
Is this a case of GIGO, or a bug. Ie, should the TZ used by the lib encompass the TZ of the lat/long
LAT=37.485215 // in redwood city california
LONG=-122.2363 //
TZ = CEST // Copenhagen
correct TZ is in PST for that lat/long
this is for 3/30 and 3/31. Sunrise on the 31st, sunset on the 30th
calculated values:
sunrise Wed Mar 30 04:31:00 CEST 2016
sunset Thu Mar 31 15:55:00 CEST 2016
Looking up the correct sunrise/sunset on datetime.com
sunrise 3/30 04:32
sunset 3/31 21:50
Sunset looks a little off.
I have a couple unusual TimeZone objects that I am having trouble using with the library. I've traced my issue to SolarEventCalculator.adjustForDST - when inDaylightTime it assumes a constant offset of 1hr.
getDSTSavings() method returns an arbitrary value.inDaylightTime, its getOffset(long date) is different depending on date, and its getDSTSavings() value is completely ignored. I'm sure that breaks a whole slew of rules (but thats the way this TimeZone object works).For the first I think the fix is to add the value of getDSTSavings (converted from ms to hours) instead of adding BigDecimal.ONE.
For the second I think the fix is to replace getDSTSavings (or 1hr) with the value of getOffset(date) - getRawOffset (converted from ms to hours), which shouldn't change anything for normal timezones (the difference will equal getDSTSavings), but should allow the unusual TimeZone to work right.
I'll also submit a pull request. Maybe the second type of timezone isn't worth accommodating, but I am thinking adjustForDST should at least use getDSTSavings instead of BigDecimal.ONE.
I'm using the computeSunsetCalendar method in the SolarEventCalculator for version 1.2 of the library and have run into a strange error.
I initiated SolarEventCalendar with lat: 44.82897, lon: -93.470116, and timezone UTC.
My inputs are:
Zenith solarZenith = Zenith.CIVIL
Calendar date = new GregorianCalendar(2017, 5, 14).
When the method is run the result is: 2017-06-14T03:01:00.000Z. The time portion is accurate, but the date should read 2017-06-15.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.