recovering date-time milliseconds w lubridate

General
1

I need to convert a iso-8601 stye date to milliseconds since the Unix epoch, and the built-in lubridate getter function doesn't seem to work, and I'm not sure why.

I'm maybe missing something fundamental and would be grateful for any assistance.

library(lubridate)
#> 
#> Attaching package: 'lubridate'
#> The following object is masked from 'package:base':
#> 
#>     date

iso_8601 <- "2018-10-05T20:51:15+0000"

# convert to time-date

my_time <- lubridate::as_datetime(iso_8601)

# this works as expected
lubridate::seconds(my_time)
#> [1] "1538772675S"

# but the following throws an error
lubridate::milliseconds(my_time)
#> Error in Ops.POSIXt(x, 1000): '/' not defined for "POSIXt" objects

Created on 2018-10-05 by the reprex package (v0.2.1)

Session info 
devtools::session_info()
#> Session info -------------------------------------------------------------
#>  setting  value                       
#>  version  R version 3.5.1 (2018-07-02)
#>  system   x86_64, darwin15.6.0        
#>  ui       X11                         
#>  language (EN)                        
#>  collate  en_US.UTF-8                 
#>  tz       America/Chicago             
#>  date     2018-10-05
#> Packages -----------------------------------------------------------------
#>  package   * version date       source         
#>  backports   1.1.2   2017-12-13 CRAN (R 3.5.0) 
#>  base      * 3.5.1   2018-07-05 local          
#>  compiler    3.5.1   2018-07-05 local          
#>  datasets  * 3.5.1   2018-07-05 local          
#>  devtools    1.13.6  2018-06-27 CRAN (R 3.5.0) 
#>  digest      0.6.15  2018-01-28 CRAN (R 3.5.0) 
#>  evaluate    0.10.1  2017-06-24 CRAN (R 3.5.0) 
#>  graphics  * 3.5.1   2018-07-05 local          
#>  grDevices * 3.5.1   2018-07-05 local          
#>  htmltools   0.3.6   2017-04-28 CRAN (R 3.5.0) 
#>  knitr       1.20    2018-02-20 CRAN (R 3.5.0) 
#>  lubridate * 1.7.4   2018-04-11 CRAN (R 3.5.0) 
#>  magrittr    1.5     2014-11-22 CRAN (R 3.5.0) 
#>  memoise     1.1.0   2017-04-21 CRAN (R 3.5.0) 
#>  methods   * 3.5.1   2018-07-05 local          
#>  Rcpp        0.12.18 2018-07-23 cran (@0.12.18)
#>  rmarkdown   1.9     2018-03-01 CRAN (R 3.5.0) 
#>  rprojroot   1.3-2   2018-01-03 CRAN (R 3.5.0) 
#>  stats     * 3.5.1   2018-07-05 local          
#>  stringi     1.2.2   2018-05-02 CRAN (R 3.5.0) 
#>  stringr     1.3.1   2018-05-10 CRAN (R 3.5.0) 
#>  tools       3.5.1   2018-07-05 local          
#>  utils     * 3.5.1   2018-07-05 local          
#>  withr       2.1.2   2018-03-15 CRAN (R 3.5.0) 
#>  yaml        2.1.19  2018-05-01 CRAN (R 3.5.0)
1 Like
2

Hey @cawthm! I'm not sure what's going on here (I was able to reproduce your problem), but it's worth noting that the sub-second functions may be deprecated soon.

Depending on your use-case, you might need to find another way around this. For example, to get the number of milliseconds as a number:

seconds(my_time) %>% as.numeric() * 1e3

FWIW, the milliseconds function—should it work properly—actually returns a period expressed in seconds, not milliseconds. I think seconds are the smallest unit, and fractions of a second are actually represented as fractions of a second. What did you want to use the milliseconds for?

4 Likes
3

Thank you very much for your response. Your point about the getter returning a period object wasn’t known and is well-taken.

I’m using the iso 8601 object as part of an authentication procedure for an API, and I was assuming that simply taking seconds * 1000 would lose some necessary resolution- ie, that it would truncate/ round some info.

A closer look at the ISO specification seems to indicate that there is no millisecond granularity.

So, here’s what I’m attempting for now, similar to your suggestion:

‘my_date_ms_from_epoch <- as.numeric(lubridate::as_datetime(iso_8601)) * 1000 %>% asString()’

If, over the weekend, I find this in fact works, I’ll mark this as solved.

Again, thanks @rensa

2 Likes
4

No worries! Hope it goes well for you :smile:

Oh! I'm not sure if this willl affect your particular result, but it might be worth comparing your current idea against converting a period to milliseconds for general robustness. Time, as you no doubt know well, can be a bit of a pain.

2 Likes