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

paulr-bv · 2018-11-27T05:54:14Z

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

The text was updated successfully, but these errors were encountered:

bthieurmel · 2019-03-07T09:50:33Z

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 · 2019-03-07T22:51:41Z

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" <[email protected]> Reply-To: datastorm-open/suncalc <[email protected]> Date: Thursday, 7 March 2019 at 8:50 pm To: datastorm-open/suncalc <[email protected]> Cc: Paul Robertson <[email protected]>, Author <[email protected]> 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 · 2019-04-23T14:43:35Z

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.

Process datetimes in UTC rather than system time zone to ensure returned date times are not offset by 1 day in `getSunlightTimes()`. Addresses the issue reported at datastorm-open#2

mstrimas · 2023-03-20T00:19:25Z

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 · 2023-08-04T10:20:37Z

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

bthieurmel · 2023-11-07T14:09:11Z

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

mstrimas · 2023-11-08T02:08:17Z

Looks great, thanks for the fix!

jpatt2 · 2024-03-18T18:29:03Z

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.

mstrimas mentioned this issue Mar 20, 2023

Process datetimes in UTC (issue #2) #14

Closed

bthieurmel pushed a commit that referenced this issue Nov 7, 2023

#2

942a966

bthieurmel mentioned this issue Nov 7, 2023

Issue with New Zealand time zone and daylight saving #8

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

paulr-bv commented Nov 27, 2018

bthieurmel commented Mar 7, 2019

paulr-bv commented Mar 7, 2019 via email

tomauer commented Apr 23, 2019 •

edited

Loading

mstrimas commented Mar 20, 2023

fegue commented Aug 4, 2023

bthieurmel commented Nov 7, 2023

mstrimas commented Nov 8, 2023

jpatt2 commented Mar 18, 2024

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

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

Comments

paulr-bv commented Nov 27, 2018

bthieurmel commented Mar 7, 2019

paulr-bv commented Mar 7, 2019 via email

tomauer commented Apr 23, 2019 • edited Loading

mstrimas commented Mar 20, 2023

fegue commented Aug 4, 2023

bthieurmel commented Nov 7, 2023

mstrimas commented Nov 8, 2023

jpatt2 commented Mar 18, 2024

tomauer commented Apr 23, 2019 •

edited

Loading