Q: What are the properties and recommendations of the different data sources offered?

[bentolor]

@forrestguice Thanks for this nice little android program.

On discovering the menu point of day/night-solstice I stumbled over "not supported by this data source". After trying the long list it seems i.e. time4a-time4j supports this, but most others don't. But I also realized a significant difference in the data (i..e. 17:18 of usable of daylight vs. 17:31).

What I miss as a user is a short overview over the different data sources, their specific properties and when to choose which?

Can someone shed some light on this?

[forrestguice]

Hi. You are right there isn't really an overview of the different data sources, or what they can do. I think this is something to be improved.

The default (time4a-noaa) should implement all the major functionality, so you should only stumble on the "not supported" message if the settings are changed - I just want to confirm that is the case, and the app isn't erroneously installing w/ the wrong default?

---

To explain the difference between the sunrisesunsetlib, ca.rmen.sunrisesunset, and Time4A sources..

The app works by defining an interface, and then implementing it several times it by wrapping various libraries. The first version was implemented using sunrisesunsetlib, a popular library that hasn't seen any development or maintenance in awhile. I think it implements an algorithm published by the NOAA in 1990 and known to somewhat inaccurate and buggy. For example, if you enable "show seconds", you'll see that this library rounds to the minute. At this point in development the app didn't show solstice/equinox (or the moon stuff) - it wasn't part of the interface (or provided by this library).

The ca.rmen.sunrisesunset implementation was next (and added just to provide an alternative). It claims to implement algorithms published to Wikipedia, and generally agrees with sunrisesunsetlib, but more accurate with fewer bugs. For example, it will report seconds (vs rounding to the minute). The app still didn't offer solstice/equinox or moon functionality (and this library doesn't provide it).

The Time4A sources were next - this is a nice library that sees active development and maintenance. It provides all sorts of functionality these other libraries are missing. The solstice/equinox and moon functionality was added to the app - the interface was extended, and the "not supported" messages displayed whenever parts are unimplemented.

To explain the difference between the various Time4A sources.. The library provides several different implementations for calculating sunrise/sunset - simple, noaa, cc, and time4j - the app provides a short blurb explaining each one (but could do a lot better explaining the differences). The "simple" algorithm is comparable to the one used by sunrisesunsetlib (e.g. rounds to the minute) and is supposed to be "fast" (sacrificing accuracy for speed). On the other hand the "time4j" algorithm is supposed to be accurate (may potentially take a long time, but I haven't seen this as an issue). One difference is that the "time4j" and "cc" sources both refine their calculations using altitude - the app doesn't offer UI for this (yet) and doesn't indicate its happening - however the refinements occur automatically whenever the location is obtained via GPS. The "noaa" source was chosen as the default as a compromise between a fast implementation and an extremely accurate one.

The differences between the Time4A sources don't extend to the solstice/moon stuff - all the time4a sources share that code (same implementation). It doesn't matter which time4a source you choose in this respect, they all do the same thing.

17:18 of usable of daylight vs. 17:31 does sound like a big difference (although a 10min discrepancy isn't unreasonable). Its possible you have stumbled on a bug in one of the libraries, the app, or both. Its hard to say without looking closely,

It looks like I've written a wall of text trying to explain the difference, and I'm not sure I succeeded. The main point is the app isn't tied to a single library (or implementation), and its through this evolution things have become so confusing.

[forrestguice]

..another major difference. The Time4A sources provide "sun position" functionality while the other sources do not. In this case the app doesn't display a message, it just hides the affected UI.

[bentolor]

Thanks you @forrestguice – I really appreciate your very extensive answer which helped me a lot to understand the differences and properties of the various data sources and the history behind.

Obviously at some time I played with the settings and choose sunrisesunsetlib – probably because of two reasons: It's listed as very first and the lib-part in the name suggested to me it uses some "data library" similary to a timezone library and I expected an even superior precision. After clearing suntimes data I can confirm that the default is indeed the intended time4j-noaa.

Short summary descriptions of the various data sources

Let me see if I was able to understand the differences and properties correctly. I also researched a little on ca.rmen.sunrisesunset in the Wikipedia talks section and in the time4a-Sourcecode to hopefully correctly summarize the details.

Library	Description
sunrisesunsetlib	(Not recommended) Rather inaccurate and sometimes buggy. Does not support GPS altitude, seconds-based calculation, solstice, equinox or current sun position. Based on „Almanac for Computers" by the USNO.
ca.rmen.sunrisesunset	(Partially recommended) Similar to sunrisesunsetlib but with reasonable precision. Does not support GPS altitude, solstice, equinox or current sun position. Based on the algorithms published by NOAA.
time4a-simple	(Not recommended) Rather inaccurate. Does not support GPS altitude. Based on „Almanac for Computers" by the USNO. Comes with support for solstice, equinox and current sun position shared by all time4a versions.
time4a-noaa	(Partially Recommended)(Default) Same algorithm like ca.rmen.sunrisesunset with reasonable precision. Does not support GPS altitude. Based on the algorithms published by NOAA. Comes with support for solstice, equinox and current sun position shared by all time4a versions.
time4a-cc	(Recommended) Good precision taking the altitude of GPS-bases locations into account. Based on „Calendrical Calculations" by Dershowitz/Reingold. Supports all features.
time4a-time4j	(Recommended) Best precision taking the altitude of GPS-based locations, the elliptic shape of the earth and typical weather conditions into account. Based on „Astronomical Algorithm" by Jean Meeus. Supports all features.

Unfortunately my summary table has become longer from what I originally wanted to achieve. By perhaps it can provide some starting point for a better description?

A few more important details I've learned

• A user should never expect a precision higher than minutes
• The precision especially of the USNO and NOAA algorithms tend to become very wrong in the polar region.
• From what I've understand time4a-time4j should provide the best precision of all algorithms and be the default from my perspective. One major difference to CC is that CC only assumes the altitude of the observer by an approximated geodetic model while time4j does it using a spheroid (WGS84) and the assumption of a standard atmosphere (for the refraction).
• The remaining major limitations that time4a-time4j can not take into account are local topology (a mountain directly in front of you) and deviating local weather conditions.

10 minutes difference

With the new knowledge I got from you I rechecked the different algorithms. I examined the various results for today based on the location "Berlin" but also based on my current GPS position which is near Stuttgart, Germany at 600m NN altitude.

Turns out: Based on a per-minute precision all algorithms are more o less in the same range, but it makes a huge difference if I switch over to the "current position" which also provides the altitude. We are talking i.e. about a 7minute gap i.e. for the sunset times.

But also time4j-time4j and time4j-noaa have a gap of 5 minutes if the altitude is available. time4j-time4j vs. time4j-cc still 3 minutes.

Overall summary

• I tried to give an overall summary and overview over the different algorithms which hopefully may be helpful to others.
• Personally I've switched to time4j-time4j and GPS-based location as I anticipated this is the best overall precision & experience I can get
• I'd propose switching the default over to time4j-time4j or time4j-cc. Probably this is only a good idea if the UI can at least can visualize which altitude it takes into account. Otherwise it may cause much confusion. I assume for the other cases it will be 0m NN.

Sorry for responding to your wall of text with another wall of text. But it was fun to research and learn a bit more about the details.

Thanks again for your reply!

[bentolor]

Issue can be closed. Just kept it open for your consideration.

[gdt]

It would be really nice to hoist the answers here to the wiki, and adjust them to what's still relevant. I also wonder why there are implementations that are known to be not so good, if better ones don't have any real downside on any device made in the last 8 years.

[forrestguice]

It would be really nice to hoist the answers here to the wiki

That is just what we'll do. 👍
I think the summary provided by bentolor is quite excellent, so I'm going to copy the bulk of it to the wiki, then close this issue.