You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@arrow.apache.org by "SHIMA Tatsuya (Jira)" <ji...@apache.org> on 2022/08/15 18:04:00 UTC

[jira] [Updated] (ARROW-17425) [R] lubridate::as_datetime() etc. in dplyr query should be able to handle time in sub seconds

     [ https://issues.apache.org/jira/browse/ARROW-17425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

SHIMA Tatsuya updated ARROW-17425:
----------------------------------
    Summary: [R] lubridate::as_datetime() etc. in dplyr query should be able to handle time in sub seconds  (was: [R] [R] lubridate::as_datetime() etc. in dplyr query should be able to handle time in sub seconds)

> [R] lubridate::as_datetime() etc. in dplyr query should be able to handle time in sub seconds
> ---------------------------------------------------------------------------------------------
>
>                 Key: ARROW-17425
>                 URL: https://issues.apache.org/jira/browse/ARROW-17425
>             Project: Apache Arrow
>          Issue Type: Improvement
>          Components: R
>    Affects Versions: 9.0.0
>            Reporter: SHIMA Tatsuya
>            Priority: Major
>
> Since the current unit is fixed to "s", an error will occur if a time containing sub-seconds is given.
> {code:r}
> "1970-01-01T00:00:59.123456789" |>
>   data.frame(x = _) |>
>   arrow::arrow_table() |>
>   dplyr::mutate(x = lubridate::as_datetime(x, tz = "UTC")) |>
>   dplyr::collect()
> #> Error in `dplyr::collect()`:
> #> ! Invalid: Failed to parse string: '1970-01-01T00:00:59.123456789' as a scalar of type timestamp[s]
> {code}
> I thought that nanoseconds should be used, but it should be noted that POSIXct is currently supposed to be converted to microseconds, as shown in ARROW-17424.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)