search

datastorm-open / suncalc

R package for calculating sun/moon positions and phases, linked to suncalc.js
Other
43 stars 10 forks source link

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

Open paulr-bv opened 5 years ago

paulr-bv commented 5 years ago

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 commented 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
paulr-bv commented 5 years ago

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.

tomauer commented 5 years ago

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 commented 1 year ago

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 commented 1 year ago

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

bthieurmel commented 9 months ago

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

mstrimas commented 9 months ago

Looks great, thanks for the fix!

jpatt2 commented 5 months ago

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.

image001