Open paulr-bv opened 5 years ago
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
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 GitHubhttps://github.com/datastorm-open/suncalc/issues/2#issuecomment-470458572, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Ab8FK4tQPkhFIpIVZNUb70v3wdDtDAy8ks5vUODpgaJpZM4Y0yI8.
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.
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.
This is still a problem. Any plans to merge the pull request? Love your package otherwise!
New version available on github, and coming soon on CRAN. If you want to test.
Looks great, thanks for the fix!
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.
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: