The accuracy of LakeMetabolizer::sun.rise.set() is relatively low with respect to suncalc::getSunlightTimes() (demonstrated below). Additionally, sun.rise.set() does not return values in the input tzone whereas getSunlightTimes() does. Do these discrepancies warrant changes to sun.rise.set()?
One solution is to nest sun.rise.set() in a clause controlled by a new method argument, which defaults to the current implementation but allows a switch to the alternative getSunlightTimes() when called upon. An additional ‘lon’ (longitude) argument would be added to meet getSunlightTimes() requirements. This solution would maintain backwards compatibility while offering improved accuracy and handling time zones if suncalc is installed (i.e. a suggested library, not a required one). I can submit these proposed changes in a pull request if you’d like.
Demo (script is located here):
Create test data (noaa = NOAA, lm = LakeMetabolizer, sc = suncalc)
> d <- create_test_data()
[100%] Downloaded 750 bytes...
[100%] Downloaded 827 bytes...
[100%] Downloaded 742 bytes...
[100%] Downloaded 824 bytes...
> head(d)
date dst noaa_rise lm_rise sc_rise noaa_set lm_set sc_set
1 2011-01-01 FALSE 2011-01-01 07:18:00 2011-01-01 07:29:44 2011-01-01 07:19:26 2011-01-01 16:30:00 2011-01-01 16:30:15 2011-01-01 16:30:56
2 2011-01-02 FALSE 2011-01-02 07:18:00 2011-01-02 07:29:22 2011-01-02 07:19:30 2011-01-02 16:31:00 2011-01-02 16:30:37 2011-01-02 16:31:46
3 2011-01-03 FALSE 2011-01-03 07:18:00 2011-01-03 07:28:59 2011-01-03 07:19:32 2011-01-03 16:32:00 2011-01-03 16:31:00 2011-01-03 16:32:39
4 2011-01-04 FALSE 2011-01-04 07:18:00 2011-01-04 07:28:33 2011-01-04 07:19:32 2011-01-04 16:33:00 2011-01-04 16:31:26 2011-01-04 16:33:33
5 2011-01-05 FALSE 2011-01-05 07:18:00 2011-01-05 07:28:05 2011-01-05 07:19:29 2011-01-05 16:34:00 2011-01-05 16:31:54 2011-01-05 16:34:28
6 2011-01-06 FALSE 2011-01-06 07:18:00 2011-01-06 07:27:35 2011-01-06 07:19:24 2011-01-06 16:35:00 2011-01-06 16:32:24 2011-01-06 16:35:26
LakeMetabolizer during standard time
> compare_to_noaa(
+ data = d,
+ source = "LakeMetabolizer",
+ daylight.savings = FALSE)
Sunrise difference:
min: -30.63
max: -0.22
avg: -12.31
Sunset difference:
min: -22.37
max: 11.51
avg: -1.58
LakeMetabolizer during daylight savings
> compare_to_noaa(
+ data = d,
+ source = "LakeMetabolizer",
+ daylight.savings = TRUE)
Sunrise difference:
min: 29.59
max: 55.42
avg: 44.58
Sunset difference:
min: 36.93
max: 66.17
avg: 53.75
suncalc during standard time
> compare_to_noaa(
+ data = d,
+ source = "suncalc",
+ daylight.savings = FALSE)
Sunrise difference:
min: -1.98
max: -0.67
avg: -1.4
Sunset difference:
min: -2.25
max: -0.22
avg: -1.12
suncalc during daylight savings
> compare_to_noaa(
+ data = d,
+ source = "suncalc",
+ daylight.savings = TRUE)
Sunrise difference:
min: -2
max: -0.55
avg: -1.25
Sunset difference:
min: -2.77
max: -0.05
avg: -1.42
Plot sun rise
Plot sun set
The accuracy of
LakeMetabolizer::sun.rise.set()is relatively low with respect tosuncalc::getSunlightTimes()(demonstrated below). Additionally,sun.rise.set()does not return values in the input tzone whereasgetSunlightTimes()does. Do these discrepancies warrant changes tosun.rise.set()?One solution is to nest
sun.rise.set()in a clause controlled by a newmethodargument, which defaults to the current implementation but allows a switch to the alternativegetSunlightTimes()when called upon. An additional ‘lon’ (longitude) argument would be added to meetgetSunlightTimes()requirements. This solution would maintain backwards compatibility while offering improved accuracy and handling time zones ifsuncalcis installed (i.e. a suggested library, not a required one). I can submit these proposed changes in a pull request if you’d like.Demo (script is located here):
Create test data (noaa = NOAA, lm = LakeMetabolizer, sc = suncalc)
LakeMetabolizer during standard time
LakeMetabolizer during daylight savings
suncalc during standard time
suncalc during daylight savings
Plot sun rise
Plot sun set
