Dates in Sunrise and Sunset results not always same as "date = " parameter

[paulr-bv]

Hi, thanks for a great package. However, I'm wondering if I've found a bug with (at least) Sunrise and Sunset times?

It appears that when a timezone being checked is behind UTC, the "date" component of Sunrise and Sunset is the "day before" the date being checked.

Examples are below:

# GOOD
# London. In UTC. Dates for sunrise and sunset same as "date = " paramater
site_lat <- 51.50507
site_lon <- -0.11299
site_tz <- "UTC"
getSunlightTimes(date = ymd("2018-11-01"), lat = site_lat, lon = site_lon, tz = site_tz, keep = c("sunrise", "sunset"))
                 date      lat      lon             sunrise              sunset
1 2018-11-01 12:00:00 51.50507 -0.11299 2018-11-01 06:54:48 2018-11-01 16:35:45


# GOOD
# Sydney. Ahead of UTC. Dates for sunrise and sunset same as "date = " paramater
site_lat <- -33.8671417236
site_lon <- 151.2071075439
site_tz <- "Australia/Sydney"
getSunlightTimes(date = ymd("2018-11-01"), lat = site_lat, lon = site_lon, tz = site_tz, keep = c("sunrise", "sunset"))
                 date       lat      lon             sunrise              sunset
1 2018-11-01 12:00:00 -33.86714 151.2071 2018-11-01 05:56:29 2018-11-01 19:23:30


# BAD?
# Los Angles. Behind UTC. Dates for sunrise and sunset are DAY BEFORE the "date = " paramater
site_lat <- 34.052235
site_lon <- -118.243683
site_tz <- "US/Pacific"
getSunlightTimes(date = ymd("2018-11-01"), lat = site_lat, lon = site_lon, tz = site_tz, keep = c("sunrise", "sunset"))   
                 date      lat       lon             sunrise              sunset
1 2018-11-01 12:00:00 34.05224 -118.2437 2018-10-31 07:12:57 2018-10-31 18:02:40

[bthieurmel]

Hi,

Which version are you using ? (sessionInfo()). I think this bug was fixed since 0.3 :

site_lat <- 34.052235
site_lon <- -118.243683
site_tz <- "US/Pacific"
getSunlightTimes(date = ymd("2018-11-01"), lat = site_lat, lon = site_lon, tz = site_tz, keep = c("sunrise", "sunset"))   

                 date      lat       lon             sunrise              sunset
1 2018-11-01 12:00:00 34.05224 -118.2437 2018-11-01 07:13:51 2018-11-01 18:01:43

[paulr-bv]

Hi, Thanks so much for your response. sessionInfo() is showing: suncalc_0.4 I’m also using: lubridate_1.7.4 Full dump is:

sessionInfo()

R version 3.5.1 (2018-07-02) Platform: x86_64-apple-darwin15.6.0 (64-bit) Running under: macOS 10.14.3 Matrix products: default BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib LAPACK: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib locale: [1] en_AU.UTF-8/en_AU.UTF-8/en_AU.UTF-8/C/en_AU.UTF-8/en_AU.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] lubridate_1.7.4 suncalc_0.4 loaded via a namespace (and not attached): [1] compiler_3.5.1 magrittr_1.5 tools_3.5.1 curl_3.2 yaml_2.2.0 Rcpp_0.12.18 V8_1.5 stringi_1.2.4 stringr_1.3.1 jsonlite_1.5 Regards, Paul. From: "B. Thieurmel" <notifications@github.com> Reply-To: datastorm-open/suncalc <reply@reply.github.com> Date: Thursday, 7 March 2019 at 8:50 pm To: datastorm-open/suncalc <suncalc@noreply.github.com> Cc: Paul Robertson <paulr@beovista.com.au>, Author <author@noreply.github.com> Subject: Re: [datastorm-open/suncalc] Dates in Sunrise and Sunset results not always same as "date = " parameter (#2) Hi, Which version are you using ? (sessionInfo()). I think this bug was fixed since 0.3 : site_lat <- 34.052235 site_lon <- -118.243683 site_tz <- "US/Pacific" getSunlightTimes(date = ymd("2018-11-01"), lat = site_lat, lon = site_lon, tz = site_tz, keep = c("sunrise", "sunset")) date lat lon sunrise sunset 1 2018-11-01 12:00:00 34.05224 -118.2437 2018-11-01 07:13:51 2018-11-01 18:01:43 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#2 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/Ab8FK4tQPkhFIpIVZNUb70v3wdDtDAy8ks5vUODpgaJpZM4Y0yI8>.

[tomauer]

I am having the same problem, but for locations ahead of UTC, it's giving me the solar times for the next day.

site_lat <- -27.53103
site_lng <- 152.8666
site_tz <- "Australia/Brisbane"
getSunlightTimes(date = as.Date("2015-12-17"), lat = site_lat, lon = site_lng, tz = site_tz, keep = c("solarNoon"))`
                 date       lat      lon           solarNoon
1 2015-12-17 12:00:00 -27.53103 152.8666 2015-12-18 11:46:04

I am using version 0.4.

[mstrimas]

I believe this is happening because date times are being converted to the users local time zone prior to calling .getTimes(). For example, calculating solarNoon for a series of locations along the equator at various longitudes using my normal time zone ("America/Los_Angeles"), the 3 most eastern locations are a day ahead of the input date.

library(lutz)
library(suncalc)
library(tidyverse)

# default system time zone
Sys.timezone()
#> "America/Los_Angeles"

# example locations along the equator at various longitudes
data <- data.frame(date = as.Date("2023-06-01"), 
                   lat = 0, 
                   lon = seq(-150, 150, by = 25)) %>% 
  mutate(tz = tz_lookup_coords(lat = lat, lon = lon,
                               method = "accurate", warn = FALSE)) 

# solar noon
data %>% 
  mutate(solar_noon = pmap(list(date = date, lat = lat, lon = lon, tz = tz),
                           getSunlightTimes,
                           keep = "solarNoon") %>% 
           map("solarNoon") %>% 
           map_chr(as.character))

#          date lat  lon                tz          solar_noon
# 1  2023-06-01   0 -150        Etc/GMT+10 2023-06-01 11:59:17
# 2  2023-06-01   0 -125         Etc/GMT+8 2023-06-01 12:19:16
# 3  2023-06-01   0 -100         Etc/GMT+7 2023-06-01 11:39:16
# 4  2023-06-01   0  -75    America/Bogota 2023-06-01 11:59:15
# 5  2023-06-01   0  -50     America/Belem 2023-06-01 12:19:15
# 6  2023-06-01   0  -25         Etc/GMT+2 2023-06-01 11:39:14
# 7  2023-06-01   0    0           Etc/GMT 2023-06-01 11:59:13
# 8  2023-06-01   0   25 Africa/Lubumbashi 2023-06-01 12:19:13
# 9  2023-06-01   0   50         Etc/GMT-3 2023-06-01 11:39:12
# 10 2023-06-01   0   75         Etc/GMT-5 2023-06-01 11:59:12
# 11 2023-06-01   0  100      Asia/Jakarta 2023-06-02 12:19:20
# 12 2023-06-01   0  125     Asia/Makassar 2023-06-02 11:39:19
# 13 2023-06-01   0  150        Etc/GMT-10 2023-06-02 11:59:19

But if I manually change my computer's timezone to "Asia/Seoul", I end up with the 5 westernmost locations being a day behind the input date.

# system time zone after manually changing it to "Asia/Seoul"
Sys.timezone()
#> "Asia/Seoul"

# solar noon
data %>% 
  mutate(solar_noon = pmap(list(date = date, lat = lat, lon = lon, tz = tz),
                           getSunlightTimes,
                           keep = "solarNoon") %>% 
           map("solarNoon") %>% 
           map_chr(as.character))
data.frame(date = as.Date("2023-06-01"), 
           lat = 0, lon = seq(-150, 150, by = 25)) %>% 
  mutate(tz = tz_lookup_coords(lat = lat, lon = lon,
                               method = "accurate", warn = FALSE)) %>% 
  mutate(solar_noon = pmap(list(date = date, lat = lat, lon = lon, tz = tz),
                           getSunlightTimes,
                           keep = "solarNoon") %>% 
           map("solarNoon") %>% 
           map_chr(as.character))

#          date lat  lon                tz          solar_noon
# 1  2023-06-01   0 -150        Etc/GMT+10 2023-05-31 11:59:08
# 2  2023-06-01   0 -125         Etc/GMT+8 2023-05-31 12:19:08
# 3  2023-06-01   0 -100         Etc/GMT+7 2023-05-31 11:39:07
# 4  2023-06-01   0  -75    America/Bogota 2023-05-31 11:59:06
# 5  2023-06-01   0  -50     America/Belem 2023-05-31 12:19:06
# 6  2023-06-01   0  -25         Etc/GMT+2 2023-06-01 11:39:14
# 7  2023-06-01   0    0           Etc/GMT 2023-06-01 11:59:13
# 8  2023-06-01   0   25 Africa/Lubumbashi 2023-06-01 12:19:13
# 9  2023-06-01   0   50         Etc/GMT-3 2023-06-01 11:39:12
# 10 2023-06-01   0   75         Etc/GMT-5 2023-06-01 11:59:12
# 11 2023-06-01   0  100      Asia/Jakarta 2023-06-01 12:19:11
# 12 2023-06-01   0  125     Asia/Makassar 2023-06-01 11:39:10
# 13 2023-06-01   0  150        Etc/GMT-10 2023-06-01 11:59:10

If I modify this line https://github.com/mstrimas/suncalc/blob/master/R/getSunlightTimes.R#L85 to replace Sys.timezone() with "UTC", this example returns the correct date regardless of the system time zone. I'll submit a PR with that change.

[fegue]

This is still a problem. Any plans to merge the pull request?
Love your package otherwise!

[bthieurmel]

New version available on github, and coming soon on CRAN.
If you want to test.

[mstrimas]

Looks great, thanks for the fix!

[jpatt2]

I am still having an issue with timezone being incorrect when using getmoontimes function from suncalc package. Others have used my same code and same df but with different (correct) results, so I can't figure out what's going on. Here is an example of what happens. Notice the days reported back aren't the same as the day I am asking for. I've tried all different code and df's, time zones, etc. Nothing is working which leads me to believe it's something in the package and with my macbook.