Varying resultant times between sunrise/sunset resources

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

[klausbrunner]

As I've worked on this topic myself, let me chime in here: what do you consider "accurate"? All sunrise/sunset calculations are based on more or less elaborate models of the solar system, usually derived from historical observations - some quite complex, some very simple. Some may consider atmospheric refraction, others not. Some implementations of the same model may be better at dealing with accumulating errors than others. So...differences in the results are unavoidable, especially under unfavourable conditions (e.g. polar regions).

If the goal is to get exactly the same results as a certain reference source, this will only work by implementing exactly the same algorithm they use. Anything else may be legitimately off up to several minutes, which may not even matter for many real-world applications: perceived sunset/sunrise is greatly affected by local topography and weather conditions, for instance.

[MenoData]

@klausbrunner is absolute right. It depends on the algorithm and the underlying model. I have myself now released a new implementation where I support two algorithms:

• algorithm of Ed Williams (used here in this library)
• NOAA-algorithm

NOAA is more precise. Therefore I have made it the default in my library. My main motivation to support sunrise/sunset-calculations is the fact that some calendars like the islamic one let the day start on sunset (not at midnight). I have also tried to realize most of the issues you have opened here, see the API of Time4J.

I wonder if this library will still be developped when looking at the commit activities and the long silence in most open issues. Otherwise, for normal geographic locations, it is fine enough and yields satisfying precision about 1-2 minutes (but not for the polar regions).