Error in seq.int(0, to0 - from, by) : 'to' must be a finite integer
Jean-Romain opened this issue · 12 comments
I cannot run a single example of the documentation/vignette. available_RGTs gives the following error.
avail_cycles = available_RGTs(only_cycle_names = TRUE)
#> Error in seq.int(0, to0 - from, by) : 'to' must be a finite integer- Linux Mint
- R 4.1.3
- IceSat2R 1.0.1
this is what I receive when I run the following code
> require(IceSat2R)
Loading required package: IceSat2R
> avail_cycles = available_RGTs(only_cycle_names = TRUE)
> avail_cycles
[1] "RGT_cycle_1" "RGT_cycle_2" "RGT_cycle_3" "RGT_cycle_4" "RGT_cycle_5"
[6] "RGT_cycle_6" "RGT_cycle_7" "RGT_cycle_8" "RGT_cycle_9" "RGT_cycle_10"
[11] "RGT_cycle_11" "RGT_cycle_12" "RGT_cycle_13" "RGT_cycle_14" "RGT_cycle_15"
[16] "RGT_cycle_16"on
- Linux Mint
- R 4.1.1
- IceSat2R version 1.0.1
I removed and re-installed the IceSat2R package from CRAN
I also ran the previous code snippet on Rstudio Cloud with the following Operating System Specifications
> Sys.info()
sysname
"Linux"
release
"5.4.0-1061-aws"
version
"#64~18.04.1-Ubuntu SMP Fri Dec 3 17:59:13 UTC 2021" The result is the same
> require(IceSat2R)
Loading required package: IceSat2R
> avail_cycles = available_RGTs(only_cycle_names = TRUE)
> avail_cycles
[1] "RGT_cycle_1" "RGT_cycle_2" "RGT_cycle_3" "RGT_cycle_4" "RGT_cycle_5" "RGT_cycle_6"
[7] "RGT_cycle_7" "RGT_cycle_8" "RGT_cycle_9" "RGT_cycle_10" "RGT_cycle_11" "RGT_cycle_12"
[13] "RGT_cycle_13" "RGT_cycle_14" "RGT_cycle_15" "RGT_cycle_16"
The problem comes from the fact avail_urls contains NAs
Url RGT Date_from Date_to Type
1: https://icesat-2.gsfc.nasa.gov/sites/default/files/page_files/antarcticaallorbits.zip Antarctic Orbit <NA> <NA> Nominal
2: https://icesat-2.gsfc.nasa.gov/sites/default/files/page_files/arcticallorbits.zip Arctic Orbit <NA> <NA> Nominal
3: https://icesat-2.gsfc.nasa.gov/sites/default/files/page_files/ICESat2groundtracksWesternHem.zip Western Hemisphere Ground Tracks <NA> <NA> Nominal
4: https://icesat-2.gsfc.nasa.gov/sites/default/files/page_files/ICESat2groundtracksEasternHem.zip Eastern Hemisphere Ground Tracks <NA> <NA> Nominal
5: https://icesat-2.gsfc.nasa.gov/sites/default/files/page_files/IS2_RGTs_cycle1_date_time.zip IS2_RGTs_cycle1_date_time <NA> <NA> Time_Specific
6: https://icesat-2.gsfc.nasa.gov/sites/default/files/page_files/IS2_RGTs_cycle2_date_time.zip IS2_RGTs_cycle2_date_time <NA> <NA> Time_Specific
7: https://icesat-2.gsfc.nasa.gov/sites/default/files/page_files/IS2_RGTs_cycle3_date_time_0.zip IS2_RGTs_cycle3_date_time_0 <NA> <NA> Time_Specific
[...]
Then all dates are broken
Line 62 of latest_orbit
dates_spec
[[1]]
[1] "October 13 2018" "December 28 2018"
[[2]]
[1] "December 28 2018" "March 29 2019"
[[3]]
[1] "March 29 2019" "June 28 2019" Then
dates_spec = lapply(dates_spec, function(x) {
as.character(as.Date(x, format = "%b %d %Y"))
})
dates_spec
[[1]]
[1] NA NA
[[2]]
[1] NA NA
[[3]]
[1] NA NAMinimal reproducible example on my computer
as.Date("October 13 2018", format = "%b %d %Y")
> [1] NAFor some reason you receive NA's for "Date_from" and "Date_to" whereas these 2 columns should have either NA's or dates
The available_RGTs() function attempts first to download the latest metadata from the technical_specs_url by using the latest_orbits() function (using internally the "rvest" R package). The NA's correspond by default to the "Nominal" and not to the "Time_specific" Type
https://stackoverflow.com/questions/15566875/as-date-returning-na-while-converting-from-ddmmmyyyy
To put that in relationship to openjournals/joss-reviews#4342:
- Pay attention to system locale.
- Write unit tests related to system locale.
- Read about system locale (on my side I know nothing and I don't like manipulating dates 😉 )
- Do not add
Sys.setlocale("LC_TIME", "C")in your code. You are not allowed to change user's settings.
Sys.getlocale("LC_TIME")
#> [1] "fr_CA.UTF-8"
as.Date("October 13 2018", format = "%b %d %Y")
#> [[1] NA
lct <- Sys.getlocale("LC_TIME"); Sys.setlocale("LC_TIME", "C")
#> [[1] "C"
as.Date("October 13 2018", format = "%b %d %Y")
#> [[1] "2018-10-13yes, it is a system locale issue, as per definition
%b
Abbreviated month name in the current locale on this platform. (Also matches
full name on input: in some locales there are no abbreviations of names.)
In my Operating System
> dates_spec = list(c("October 13 2018", "December 28 2018"))
> dates_spec
[[1]]
[1] "October 13 2018" "December 28 2018"
> dates_spec = lapply(dates_spec, function(x) {
+ as.character(as.Date(x, format = "%b %d %Y"))
+ })
> dates_spec
[[1]]
[1] "2018-10-13" "2018-12-28"The only way to warn a user and avoid this issue is to throw an error
I don't think so. There are plenty of packages dealing with dates. You just need to learn how to handle it the right way.
yes, I'll take a look this week and I'll proceed to the unavoidable to create tests for functions that download data from the web. thanks for making me aware of this issue
- I've modified the code as I mention in the NEWS.md file
- I've also included tests for the cases where the functions download data. The user of the R package can test all files or specific ones as I mention in the README.md file
- Regarding the system locale, I ended up modifying the code so that the dates are processed as character strings and the previous conversion does not take place.
I close this issue for now, as I fixed the error case by modifying the code. Feel free to re-open it in case the code does not work as expected.