timestamp parsing fails
BenoitFayolle opened this issue · 12 comments
library(riem)
head(riem_measures(
station = "VOHY",
date_start = "2014-03-01",
date_end = "2014-04-05"
))
#> Warning: All formats failed to parse. No formats found.
#> # A tibble: 6 × 32
#> station valid lon lat tmpf dwpf relh drct sknt p01i
#> <chr> <dttm> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
#> 1 VOHY NA 78.5 17.5 69.8 60.8 73.1 130 4 0
#> 2 VOHY NA 78.5 17.5 69.8 60.8 73.1 190 4 0
#> 3 VOHY NA 78.5 17.5 77 62.6 61.1 120 6 0
#> 4 VOHY NA 78.5 17.5 82.4 64.4 54.6 180 5 0
#> 5 VOHY NA 78.5 17.5 84.2 64.4 51.5 120 6 0
#> 6 VOHY NA 78.5 17.5 87.8 64.4 45.9 210 5 0
#> # … with 22 more variables: alti <dbl>, mslp <lgl>, vsby <dbl>, gust <lgl>,
#> # skyc1 <chr>, skyc2 <chr>, skyc3 <chr>, skyc4 <chr>, skyl1 <dbl>,
#> # skyl2 <dbl>, skyl3 <dbl>, skyl4 <dbl>, wxcodes <chr>,
#> # ice_accretion_1hr <lgl>, ice_accretion_3hr <lgl>, ice_accretion_6hr <lgl>,
#> # peak_wind_gust <lgl>, peak_wind_drct <lgl>, peak_wind_time <lgl>,
#> # feel <dbl>, metar <chr>, snowdepth <lgl>
Changed this line to :
result$valid <- lubridate::as_datetime(result$valid,format="%F %H:%M")
to fix
Thank you! Would you like to make a pull request?
Sure do I need to fork the repo to be able to make the PR?
Yep! Useful reads
- https://happygitwithr.com/fork-and-clone.html
- https://usethis.r-lib.org/articles/pr-functions.html
I'm happy to answer any question!
When you make the PR please also update the NEWS.md
file, indicating the issue number and your GitHub username as was done in https://github.com/ropensci/riem/blob/master/NEWS.md#riem-020
Thank you!
@BenoitFayolle thanks for the PR! I am actually not able to reproduce the bug (but the code still works with the PR changes): which lubridate version are you using? Are you using a special option for lubridate?
that's odd !
R version 4.2.2 (2022-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Linux Mint 21Matrix products: default
BLAS: /usr/local/lib/R/lib/libRblas.so
LAPACK: /usr/local/lib/R/lib/libRlapack.solocale:
[1] LC_CTYPE=fr_FR.UTF-8 LC_NUMERIC=C LC_TIME=fr_FR.UTF-8
[4] LC_COLLATE=fr_FR.UTF-8 LC_MONETARY=fr_FR.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=fr_FR.UTF-8 LC_NAME=C LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=Cattached base packages:
[1] stats graphics grDevices utils datasets methods baseother attached packages:
[1] riem_0.3.0.9000loaded via a namespace (and not attached):
[1] lubridate_1.9.0 fansi_1.0.3 utf8_1.2.2 rappdirs_0.3.3
[5] httr2_0.2.2 R6_2.5.1 lifecycle_1.0.3 jsonlite_1.8.3
[9] magrittr_2.0.3 pillar_1.8.1 rlang_1.0.6 cli_3.4.1
[13] curl_4.3.3 rstudioapi_0.14 vctrs_0.5.0 generics_0.1.3
[17] tools_4.2.2 glue_1.6.2 compiler_4.2.2 pkgconfig_2.0.3
[21] timechange_0.1.1 tibble_3.1.8
I'm not aware of anything special with my lubridate package
I can't replicate on this other machine I have :
R version 4.2.2 Patched (2022-11-10 r83330)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Linux Mint 20.3
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0locale:
[1] LC_CTYPE=fr_FR.UTF-8 LC_NUMERIC=C
[3] LC_TIME=fr_FR.UTF-8 LC_COLLATE=fr_FR.UTF-8
[5] LC_MONETARY=fr_FR.UTF-8 LC_MESSAGES=en_GB.UTF-8
[7] LC_PAPER=en_GB.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=Cattached base packages:
[1] stats graphics grDevices utils datasets methods baseother attached packages:
[1] riem_0.3.0loaded via a namespace (and not attached):
[1] lubridate_1.8.0 fansi_1.0.3 utf8_1.2.2 crayon_1.5.1 rappdirs_0.3.3
[6] httr2_0.2.2 R6_2.5.1 lifecycle_1.0.1 jsonlite_1.8.0 magrittr_2.0.3
[11] pillar_1.7.0 rlang_1.0.6 cli_3.3.0 curl_4.3.2 rstudioapi_0.13
[16] vctrs_0.4.1 ellipsis_0.3.2 generics_0.1.2 tools_4.2.2 glue_1.6.2
[21] compiler_4.2.2 pkgconfig_2.0.3 tibble_3.1.8
@BenoitFayolle do you mean that you do NOT see the bug you had reported on your other machine?
On the initial machine where I have the bug (lubridate 1.9.0) this is what I get:
ymd_hm("2022-01-01 00:00")
It's actually an identified lubridate 1.9.0 bug
I run the code on my machine and can't reproduce the error. This is my result
# A tibble: 6 x 32
station valid lon lat tmpf dwpf relh drct sknt p01i
<chr> <dttm> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
1 VOHY 2014-03-01 00:40:00 78.5 17.5 69.8 60.8 73.1 130 4 0
2 VOHY 2014-03-01 01:40:00 78.5 17.5 69.8 60.8 73.1 190 4 0
3 VOHY 2014-03-01 03:40:00 78.5 17.5 77 62.6 61.1 120 6 0
4 VOHY 2014-03-01 05:40:00 78.5 17.5 82.4 64.4 54.6 180 5 0
5 VOHY 2014-03-01 07:40:00 78.5 17.5 84.2 64.4 51.5 120 6 0
6 VOHY 2014-03-01 08:40:00 78.5 17.5 87.8 64.4 45.9 210 5 0
# ... with 22 more variables: alti <dbl>, mslp <lgl>, vsby <dbl>, gust <lgl>,
# skyc1 <chr>, skyc2 <chr>, skyc3 <chr>, skyc4 <chr>, skyl1 <dbl>,
# skyl2 <dbl>, skyl3 <dbl>, skyl4 <dbl>, wxcodes <chr>,
# ice_accretion_1hr <lgl>, ice_accretion_3hr <lgl>, ice_accretion_6hr <lgl>,
# peak_wind_gust <lgl>, peak_wind_drct <lgl>, peak_wind_time <lgl>,
# feel <dbl>, metar <chr>, snowdepth <lgl>
# i Use `colnames()` to see all variable names
@BenoitFayolle in that case should your PR change the minimal lubridate version to 1.9.0.9000 in DESCRIPTION? Then once lubridate 1.9.1 is on CRAN I can tweak the DESCRIPTION and submit riem to CRAN.
Didn't know that trick @maelle
I updated the PR, let me know if that's what you meant