Varying resultant times between sunrise/sunset resources

[mikereedell]

Varying resultant times between sunrise/sunset resources

[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).