You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think this is related to #502 so if the answer is "POSIXct precision < 1 second isn't expected", then please let me know. Also related to tidyverse/readr#1394 in some ways.
Issue
Fractional seconds are not being converted one-to-one.
Overall issue is that I have data in a datatime format and I needed to convert datetimes with milliseconds (high frequency accelerometer signals) to a character and checks failed because the original data and the written data are now discrepant and I am trying to understand why.
This also related to readr functionality for reading in dates @jennybc
library(readr)
library(lubridate)
#> #> Attaching package: 'lubridate'#> The following objects are masked from 'package:base':#> #> date, intersect, setdiff, union
library(dplyr)
#> #> Attaching package: 'dplyr'#> The following objects are masked from 'package:stats':#> #> filter, lag#> The following objects are masked from 'package:base':#> #> intersect, setdiff, setequal, union
options(digits.secs=3)
print_wide=function(df) {
print(df, width=1000)
}
Create a Data set
The record in question is record 2 and the milliseconds (987) and how that is transformed
y= read.csv(tfile)
y=tibble::as_tibble(y)
print_wide(y)
#> # A tibble: 2 × 4#> time x y z#> <chr> <dbl> <dbl> <dbl>#> 1 2012-05-16 08:35:32.974 -0.909 0.182 -0.589#> 2 2012-05-16 08:35:32.987 -0.927 0.082 -0.381
Time is 987 for the milliseonds
print_wide(y)
#> # A tibble: 2 × 4#> time x y z#> <chr> <dbl> <dbl> <dbl>#> 1 2012-05-16 08:35:32.974 -0.909 0.182 -0.589#> 2 2012-05-16 08:35:32.987 -0.927 0.082 -0.381# remove unneded columns y=y %>%
select(-x, -y, -z)
as_datetime turns it into 986, though numerically it’s still 987, but
when converting to character it is 986
y$new_time=lubridate::as_datetime(y$time)
It is stored numerically as 987
as.numeric(y$new_time)[2] %%1#> [1] 0.987
Now format/strftime use 986 when converting to char, baking the 986 in vs 987. This is the main issue I see with the conversion and I don’t understand exactly why.
strptime gives back 987 however and works. This is a partial solution (do not use readr::read_csv (as below), and use strptime to get the exact data back).
x=readr::read_csv(tfile)
#> Rows: 2 Columns: 4#> ── Column specification ────────────────────────────────────────────────────────#> Delimiter: ","#> dbl (3): x, y, z#> dttm (1): time#> #> ℹ Use `spec()` to retrieve the full column specification for this data.#> ℹ Specify the column types or set `show_col_types = FALSE` to quiet this message.
print_wide(x)
#> # A tibble: 2 × 4#> time x y z#> <dttm> <dbl> <dbl> <dbl>#> 1 2012-05-16 08:35:32.973 -0.909 0.182 -0.589#> 2 2012-05-16 08:35:32.986 -0.927 0.082 -0.381x=x %>%
select(-x, -y, -z)
We see the same results here as lubridate such that format/strftime will embed the 986
I think this is related to #502 so if the answer is "
POSIXct
precision < 1 second isn't expected", then please let me know. Also related to tidyverse/readr#1394 in some ways.Issue
Fractional seconds are not being converted one-to-one.
Overall issue is that I have data in a datatime format and I needed to convert datetimes with milliseconds (high frequency accelerometer signals) to a character and checks failed because the original data and the written data are now discrepant and I am trying to understand why.
This also related to
readr
functionality for reading in dates @jennybcCreate a Data set
The record in question is record 2 and the milliseconds (987) and how that is transformed
We can confirm second record it is still 987
Read the data in using read.csv
Time is 987 for the milliseonds
as_datetime
turns it into 986, though numerically it’s still 987, butwhen converting to character it is 986
It is stored numerically as 987
Now format/strftime use 986 when converting to char, baking the 986 in vs 987. This is the main issue I see with the conversion and I don’t understand exactly why.
Digits does nothing
Here we try different methods for extracting the date (
parse_date_time
, whichas_datetime
uses), with the same resultsTrying with
train = FALSE
strptime
gives back 987 however and works. This is a partial solution (do not usereadr::read_csv
(as below), and usestrptime
to get the exact data back).Using
read_csv
We see the same results here as
lubridate
such thatformat
/strftime
will embed the 986And now writing out the result now has 986 embedded, not 987
Created on 2024-04-24 with reprex v2.1.0
Session info
The text was updated successfully, but these errors were encountered: