ropensci/riem

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

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 21

Matrix products: default
BLAS: /usr/local/lib/R/lib/libRblas.so
LAPACK: /usr/local/lib/R/lib/libRlapack.so

locale:
[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=C

attached base packages:
[1] stats graphics grDevices utils datasets methods base

other attached packages:
[1] riem_0.3.0.9000

loaded 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.0

locale:
[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=C

attached base packages:
[1] stats graphics grDevices utils datasets methods base

other attached packages:
[1] riem_0.3.0

loaded 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